这是一个创建于 777 天前的主题，其中的信息可能已经有所发展或是发生改变。
现在在一家小公司里帮忙做一些数据处理，金融方面的。数据都是从人工处理过的 Excel 里来的。目前数据放进 SQLite 里大概数据库文件大小在 500MB 左右。后续可能会增长到几百 GB 。
因为 SQLite 简单，不需要解决配置，端口，用户名，等等复杂问题。即开即用。
那以后到了什么时候就该从 SQLite 换到 MySQL 了呢？或者换到 SQL Server ？
 |
1
perfectlife 2022-09-30 13:11:21 +08:00
从设计时候应该就开始，尤其是预测会增长到几百 GB,用个 mysql 也不费啥劲
|
 |
2
arch9999 2022-09-30 13:15:08 +08:00
迁移起来也简单，但是不加工资就先别搞了。
|
 |
3
mejee 2022-09-30 13:18:18 +08:00
肯定是 MySQL ，有相对专业成熟的维护、备份等。sqlLite 是方便，不需要解决配置，端口，用户名，等等复杂问题，但是硬盘坏了呢？服务挂了呢
|
 |
4
iseki 2022-09-30 13:19:43 +08:00 via Android
换也不妨去换 SQL Server 或者 PostgreSQL ，MySQL 就没必要了吧
|
|
5
iseki 2022-09-30 13:20:08 +08:00 via Android
暴论
|
 |
6
dcsuibian 2022-09-30 13:21:29 +08:00  1
SQLite 的读写效率很高，有哪些使用其他数据库的理由？ - zzl0 的回答 - 知乎
https://www.zhihu.com/question/31417262/answer/881191147 SQLite 文档指出了什么时候用 client/server SQL 数据库（如 MySQL ） 1 、Is the data separated from the application by a network? → choose client/server 2 、Many concurrent writers? → choose client/server 3 、Big data? → choose client/server 4 、Otherwise → choose SQLite! |
 |
7
MrLonely OP @perfectlife 主要是这团队里就我一个人会代码，别的地方要花的时间也不少。想先各个方面都搞到能跑起来。但又想心里有数什么时候就改换数据库了。
@mejee SQLite 就一个文件，暂时用 NAS 备份。MySQL 那些专业的方案我现在都没了解过啊。有什么博客或者链接推荐一下，我去了解了解吗？ @iseki 这是为啥呀？可以展开讲讲吗？ |
 |
8
mxT52CRuqR6o5 2022-09-30 13:27:25 +08:00 via Android
我觉得直接折腾 excel 的函数就行了
|
 |
9
ipwx 2022-09-30 13:33:01 +08:00
我觉得金融数据一股脑扔给 MySQL 也不行，时序数据的支持，关系数据库都比较那啥。
提高速度的关键在于自己分库分表，优化时间序列的索引方式。但说实话如果你能做到这一步，用 SQLite 你也能做。另一方面金融数据库一般很多时候会用来做实验，如果你能用 SQLite 解决这些事情，你天然多了一种在实验机器上本地缓存数据的方案，这样可以大大减轻你 MySQL 中央数据库的压力。 退一步你也可以使用 MySQL 中央数据库 + SQLite 本地缓存的模式。 |
 |
10
chendl111 2022-09-30 13:35:24 +08:00
一开始就应该换，做好分库分表，主备同步，在出事的时候才好处理
|
 |
11
Rocketer 2022-09-30 13:37:25 +08:00 via iPhone
难道不应该用接口 /实现类来做到随便换数据库吗？将来也许会发展到 mysql 也撑不住，那时换 oracle 就是最快能上线的选择。
|
 |
12
janus77 2022-09-30 13:39:59 +08:00
高级特性，比如数据的版本控制、备份、事务、回滚、多个服务同时读写时的一致性、吞吐量较大等情况下的性能、需要支持较复杂的表结构和查询语句
安全，你现在不需要用户名密码不代表以后不要。用户名密码也是安全配置的一部分。还有 MySQL 针对漏洞的安全补丁，MySQL 支持的加密特性等 |
 |
13
Mithril 2022-09-30 13:40:27 +08:00 1
不需要，SQLite 的性能其实很好。
之前测过单表两千万的库也就才 40G 的文件，性能一样可以接受。 而且备份极其简单，特别是你客户没有专业运维的时候，告诉他们下班停了程序文件复制一份就行了。 想要判断什么时候放弃，那就要想清楚你的程序的生命周期。在这个生命周期内，你打算支持多大量的数据，什么样的业务模式。 如果你的程序单机跑没法满足需求，那么可能数据库也要考虑替换。 如果你的程序单机足够满足需求了，没那么大负载也没有高可用需求，那么 SQLite 就是最好的选择。 |
 |
14
line 2022-09-30 13:41:51 +08:00
多台服务器，共用一个数据库， 这个 sqlite 就不行吧。
|
 |
17
liuzhaowei55 2022-09-30 13:44:52 +08:00 via iPhone
看场景并不需要换 MySQL ，就自己使用，也没有大并发的需求，至于数据量的增长做好数据分库，一类数据搞一个文件就行了，啥维护成本都没有
|
|
18
Mithril 2022-09-30 13:49:52 +08:00
另外，所谓安全性更不需要考虑。
当一个人可以物理访问到你的机器时，你就可以认为已经被公婆了。 从这方面考虑，SQLite 的安全性远超所有其它数据库。 更别说 SQLite 你可以加密数据文件，但其实意义不大。能接触到数据库文件，说明也能接触到你的程序文件，更别说你这还是服务器，挂个 debugger 连内存都能 dump 出来。这种情况下讨论安全配置没什么意义。 |
 |
20
fournoas 2022-09-30 13:55:52 +08:00
你这个情景暂时不需要 mysql ，做好数据文件备份就行了
|
 |
21
fds 2022-09-30 14:03:41 +08:00
@Mithril SQLite 可以不停程序直接备份吗？前段时间看 https://litestream.io/ 这种专门的备份软件应该是支持。但不确定直接文件复制会不会出错。
|
|
22
Mithril 2022-09-30 14:10:21 +08:00 1
|
 |
23
nekoneko 2022-09-30 14:46:45 +08:00
高并发下换, 数据量大了换
|
 |
24
tigerstudent 2022-09-30 14:56:07 +08:00
以前一单机项目用 SQLite ，不知道怎么回事，个别机器（多台）会偶发 SQLite 文件损坏
|
 |
26
billzhuang 2022-09-30 15:02:39 +08:00
开启 WAL ，https://www.sqlite.org/wal.html
做好文件备份，熬到你离职，问题不大。 |
 |
27
mywaiting 2022-09-30 15:55:11 +08:00
只要是单机版，SQLite 能吊打其他数据库，无论性能还是代码实现的容易程度
什么时候放弃用 SQLite ，那就是你放弃单机版的实现的时候 相对客观地说，这个世界大多数的应用都熬不过需要从 SQLite 转换到 MySQL 分库的时候 |
 |
28
akira 2022-09-30 23:07:35 +08:00
这数据值钱不。。损坏了能接受不 。。或者丢一天的数据你们要亏多少。。
|
 |
31
wxf666 2022-10-03 01:18:27 +08:00
|
 |
32
yingluck 2022-10-11 17:54:14 +08:00
1. 数据库大小，是否超过 281TB, 超过就用 MySQL
2. 并发写多不多，sqlite3 写操作会锁表，有并发写就换其他的 3. 操纵数据库的程序和数据库在不在一台机器上，不在的话 sqlite3 不合适 |
Select Language