摘要：就像是使用 .txt文本文件 那样直接和项目住在 #技术分享一起。【说高级一些叫 嵌入式-集成在应用程序中 】，而不是mysql那样单独起一个服务。跨平台（win/mac/linux）【轻量级】，整个库体积小、资源占用很少！往往只有几百KB。可以说这一点是它最
最近在将包含 mysql 的项目打包成镜像的时候，感觉 mysql 的镜像是真的大，拉取下来要很久。
【因为本人的服务器配置比较拉胯，所以在windows上拉还可以，但是在服务器拉就很难受了】
就在想是不是可以换成 sqlite，我的印象中对 sqlite 的印象就是它占用内存小。
既然占用内存小，那是不是在其他的某些方面做了妥协呢？
今天主要就来讲讲这个。
就像是使用 .txt文本文件 那样直接和项目住在 #技术分享一起。【说高级一些叫 嵌入式-集成在应用程序中 】，而不是mysql那样单独起一个服务。跨平台（win/mac/linux）【 轻量级 】，整个库体积小、资源占用很少！往往只有几百KB。可以说这一点是它最大的优势。备份 很方便：复制粘贴就是备份了。补充：
一般什么时候会用到sqlite？
答：
在需要快速开发出一个简单的、能用的功能【也叫做 Minimum Viable Product ，缩写是 MVP —— 最小可用功能 】、再去慢慢优化的场景下就比较合适了。
我可以用 sqlite 去存数据， express 快速写一些测试接口，再配合 xxx.http文件+vscode中的【REST Client】插件进行飞速的接口调试 。
上面的操作就叫 原型开发 ，原型开发好之后我可以再去按照业务的实际情况去替换 sqlite 为更合适的数据库，也可以将 express 换成更加适合企业的 nest 等等等等操作。
那么 sqlite 这些优点背后的代价是什么？
不适合高并发，多人同时【写】会出问题【就这一点就决定了生产环境的大部分业务不会用它，所以它的缺点反而没那么重要了】读写文件操作频繁会发生卡顿（因为中间没有服务器层做调节，而是直接进行文件操作）只能本地访问，不能像mysql那样，输入一个ip，一个用户名密码就可以全世界访问。最后来总结一下什么时候用 sqlite，什么时候不该用 sqlite。
当需要进行原型开发、或者服务器巨卡无比，服务器资源很少了的时候，且没有啥高并发的情况下（当然，服务器巨卡+没服务器资源也别想高并发了）就可以考虑 sqlite。
当应用需要支持高并发的时候，直接 pass sqlite！
来源：墨码行者
