前言
最近在将包含mysql的项目打包成镜像的时候，感觉mysql的镜像是真的大，拉取下来要很久。
【因为本人的服务器配置比较拉胯，所以在windows上拉还可以，但是在服务器拉就很难受了】
就在想是不是可以换成sqlite，我的印象中对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！