网站开发数据库对比

上个月帮朋友迁移一个日活两千左右的网站小型电商站，原本跑在SQLite上，开发库对结果订单表一过十万行，数据后台查个“最近七天未发货订单”要等三秒多。网站换到PostgreSQL后，开发库对同样的数据查询降到80毫秒。这不是网站SQLite不行，是开发库对它本来就不该干这个活。选数据库这件事，数据很多人第一步就错了——不是网站先问“哪个最好”，而是开发库对先搞清楚你的数据要长成什么样、怎么被读写。数据

关系型数据库里，网站PostgreSQL和MySQL是开发库对绕不开的两个选项。MySQL在互联网公司里铺得最广，数据尤其是早期PHP时代留下来的遗产，很多运维闭着眼都能调优。但PostgreSQL这几年追得很猛，JSON字段支持、窗口函数、CTE、地理空间查询，几乎把MySQL按在地上摩擦。我自己的经验是：如果你的业务涉及复杂查询、报表统计、或者数据结构变来变去，PostgreSQL省心得多。反过来，如果就是简单的读写、高并发插入、团队又全是MySQL老手，硬上PG反而增加沟通成本。

SQLite是个特例。它没有网络层，整个数据库就是一个文件，读性能极好，写性能受限于文件锁。适合什么场景？个人博客、移动端App本地缓存、小型内部工具。我见过有人拿它跑日活过万的社区，勉强能撑，但一旦出现并发写，就开始报database is locked。所以别被“轻量”两个字骗了，轻量不等于万能。

NoSQL这边，MongoDB的文档模型确实让早期开发爽快。不用建表、不用改schema，直接塞JSON。但爽快是有代价的——数据一乱，后期查询和维护就变成噩梦。我见过一个创业团队用MongoDB存订单，半年后想按“用户地区+商品类目+下单时间段”做聚合，写了三百多行聚合管道，跑一次要十几秒。后来他们老老实实把订单数据同步到PostgreSQL做分析。MongoDB适合什么？日志、爬虫数据、内容管理里那些结构不固定的部分。别拿它当主业务库使。

Redis是另一回事。它压根不是用来替代关系库的，而是做缓存、会话、排行榜、消息队列。我习惯在PostgreSQL前面加一层Redis，热点数据放Redis，复杂查询走PG。但要注意：Redis持久化不是100%可靠，AOF加RDB混合模式也可能丢最后几秒的数据。所以别把唯一一份订单数据只放Redis里，那是给自己挖坑。

再说一个容易被忽略的点：数据库的运维成本。PostgreSQL的MVCC机制导致表膨胀问题，需要定期vacuum，autovacuum调不好就拖慢性能。MySQL的InnoDB相对省心，但DDL操作（比如加索引）在早期版本会锁表，5.7之后才好些。MongoDB的副本集配置比PG的流复制简单，但分片集群的坑一点不少。选数据库不只是选功能，也是选你愿意花多少时间伺候它。

最后给个粗暴的判断逻辑：数据关系复杂、需要事务、查询多变——PostgreSQL。高并发简单读写、团队熟悉——MySQL。单机小工具、嵌入式——SQLite。文档结构为主、schema频繁变动——MongoDB。缓存和高速读写——Redis。没有银弹，只有取舍。我自己的主力组合是PostgreSQL + Redis，偶尔用SQLite做本地原型。这套组合撑住了好几个中小型项目，没出过大乱子。