SQLite 可以用作线上数据库吗？

• 資深大佬 : xuanbg

  合适

• 資深大佬 : way2explore2

  if 1000 users are all online at the same time, definetely not.

• 資深大佬 : qping

  sqlite 没法支持并发写吧，只是并发读应该可以

• 資深大佬 : stardustree

  先试试，崩了再说呗 (●’◡’●)

• 主 資深大佬 : lynan

  功能是用户 a 提交表单，用户 b 提交反馈。同时在线人数应该不多，用户提交表单这个行为是低频的。

• 主 資深大佬 : lynan

  用户 b 对用户 a 提交的表单进行反馈。

• 資深大佬 : gstqc

  合适，没问题

• 資深大佬 : kaka6

  正常没问题，并发量大时就会有问题，必竟是文件数据库，有 IO 瓶颈

• 資深大佬 : havemail

  肯定是不合适，但是如果你加个 Redis 缓存 还是可以的一试，毕竟功能简单而且 QPS 不会太高，1000 用户只是表单提交没啥并发，上线前最好是做一次压测，看看瓶颈在哪。

• 資深大佬 : love

  1000 用户同时在线都没问题

• 資深大佬 : jason19659

  没啥问题,用文件写都行

• 資深大佬 : unclemcz

  性能应该问题不大的，数据管理是个问题，sqlite 应该无法远程运维。
  我自己的一个项目放云上，用 sqlite 运行了差不多一年不到的样子，后来实在是太麻烦了，每次数据运维都要登录服务器，现在换 mysql 了。

• 資深大佬 : jorneyr

  @qping 这才是最重要的。

• 資深大佬 : Soar360

  hummm… SQLite 是库级锁哦。

• 資深大佬 : qwerthhusn

  装个 mysql 或者 postgres 也是分分钟的事。资料也多，解决问题方便。
  以后用起来使用成本肯定比 SQLLite 要低，而且万一以后扛不住了，也很好扩展

• 資深大佬 : IDAEngine

  还是别用 SQLLite 吧，管理维护太麻烦了，还不如装个 sqlserver 免费版

• 資深大佬 : lqw3030

  加一个降级方案，保证扛不住的时候数据不丢

• 資深大佬 : yimity

  sqlite 和 MySQL 在使用上没什么特别大的差别，但是 MySQL 会带来特别多的好处。
  所以不清楚线上站点，总是想用 sqlite 是为了什么？

• 資深大佬 : securityCoding

  图什么？

• 資深大佬 : kiracyan

  sqlite 一般都做单机数据库的吧

• 資深大佬 : misaka19000

  这个和用户数量没关系吧，主要是看 QPS，如果 1000 个用户只有 100 个子线，而同时只有 10 个用户在进行数据操作，那么 SQLite 显然是没问题的

• 資深大佬 : yinzhili

  以后如果确定不需要扩展的话就可以

• 資深大佬 : xumng123

  不方便，从 sqlite 迁移到 mysql 巨麻烦，导出的脚本各种不兼容

• 資深大佬 : lawler

  用 H2 吧，至少有在线管理数据库。

• 資深大佬 : roundgis

  用了六七年了，一點問題都沒有

• 資深大佬 : real3cho

  SQL Server Express 它不香吗？

• 資深大佬 : opengps

  这个问题，跟我当年了解云是虚拟机时候一样的感觉。
  一直觉得虚拟机只是本地玩玩，然而现在的云却几乎全是虚拟机。
  决定是否可以用于线上的主要因素并非大小体积等，而是看他是否能解决一些线上的问题，任何东西放在有用的地方就是好东西

• 資深大佬 : bagheer

  github 上有一个 rqlite 项目,用 sqlite 做存储, 做了分布式.(默认全内存)

• 資深大佬 : Nich0la5

  尽量不要 sqlite 抗不住高并发

• 資深大佬 : libook

  从项目本身的靠谱性上来说，SQL 可以拿来做企业级应用的。

  但数据库一大堆，各有特色，选哪个要结合你的实际需求来看。

  最直观的方式就是模拟用户使用情况，然后做压测，比如你有 1000 个用户，就搞 2000 个模拟用户试试，看看能不能扛得住。

  要是负载巨低，数据量超小，你搞个 yaml 自己写程序读写也成，读操作就直接在内存里操作，写操作就更新文件。

  或者你还是不知道用啥合适，就用主流方案，比如 MySQL 、SQLServer 。

• 資深大佬 : MrTLJH

  目前我就在用，用户每天 1000 个左右，没并发就没问题

• 資深大佬 : areless

  这个可以跑在内存中，还能跑在显存中～用 gpu 加速 sql 只要执行的快 库锁级不是问题～直接锁电脑都没问题呀

• 資深大佬 : c00WKmdje2wZLrSI

  @unclemcz navicat 有个 http 隧道功能，可以远程 sqlite

• 資深大佬 : lithbitren

  跑在内存里，sqlite 作为内存的持久化，怎么并发问题都不大

• 資深大佬 : kosmgco

  https://turriate.com/articles/making-sqlite-faster-in-go

• 資深大佬 : vanityfairn

  h2,有个管理页面，哈哈哈哈。我最近也是在搞内存数据库做个人小项目。用 mysql，对个人而言嫌贵了。

• 資深大佬 : ibcker

  最好不要，不要问我是怎么直到的。。。。逃。。。

• 資深大佬 : yufeng0681

  docker 部署一个 mysql，也不繁琐啊

• 資深大佬 : fox0001

  老哥，对未来的自己好点，还是别…

• 資深大佬 : coymail

  可以，但没必要

• 資深大佬 : xy90321

  把 sqlite 的 db 文件配置到 RAM Disk 里，然后该怎么玩就怎么玩…

• 資深大佬 : xy90321

  但是有一个建议，不要把业务直接和 sqlite 去耦合
  想办法抽象出一个 DAO 层来，然后在 DAO 里去适配具体的 DBMS
  这样在绝大部分场景下，即使被迫更换 DBMS 也都是一件可控 /可预期的事情

• 資深大佬 : nuk

  可以，除非数据太多，超过 1G 就不太合适了。

• 資深大佬 : CallMeReznov

  1000 人属于非常极限的状态了。

• 主 資深大佬 : lynan

  非常谢谢上面的热心回复，昨晚切换到 MySQL 了，用的云数据库，感觉多了一层连接，比原来使用 SQLite 慢得多（+

• 資深大佬 : ybzai90

  当然可以，宝塔不就是在用嘛

• 資深大佬 : xpresslink

  一个小项目（ 1000 个用户左右），并发用户如果 10 个毫无问题和但是 200 个差别就比较大了。
  建议不要用，还是用 Mysql 或 Postgresql，不然项目增改需求，历史数据又比较多的时候就会很痛苦。

• 資深大佬 : UserDMM

  sqlite 这东西还是不适合那么人同时搞