选数据库这事儿，我见过太多人犯迷糊了。老板一拍脑袋说要上 MySQL，技术总监非要用 Oracle，团队里还有个愣头青天天嚷嚷着 MongoDB 才是未来。结果呢？项目上线三个月，数据库崩了，数据对不上，运维叫苦连天。其实选数据库没那么玄乎，关键是要搞清楚自己到底要什么。今天我就把市面上主流的几个数据库掰开揉碎地讲，哪些坑千万别踩，哪些场景最合适，咱们一次说透。
先说 MySQL，这家伙在互联网圈子里简直是国民级的。开源免费，社区活跃，文档多得能淹死人，随便搜个报错都能找到成千上万条解决方案。但你别以为它就能包打天下。MySQL 最大的软肋在于并发写操作，一旦业务涉及大量频繁的更新和删除，它的行锁机制就会让你头疼。我见过一个电商项目，促销期间每秒几千个订单，MySQL 的 binlog 和 redo log 差点把磁盘撑爆，最后不得不切到分库分表方案。所以 MySQL 适合读多写少的场景，比如内容管理系统、博客论坛、轻量级电商。如果要处理复杂的分析查询，或者海量数据的实时写入，趁早换个思路。
再说 Oracle，这玩意儿在银行和证券行业简直是神一样的存在。它的 ACID 事务一致性做得极其强大，基本上能做到数据零丢失。而且 Oracle 的优化器非常聪明，你写个烂 SQL，它也能硬生生优化出几分效率。但代价是什么？贵，贵得离谱。企业版授权动辄几十万、上百万，还得按 CPU 核心数算钱。而且它的运维门槛高得吓人，普通 DBA 根本搞不定那些参数调优和表空间管理。我有个朋友在保险公司做技术负责人，他们那套 Oracle 系统每年光运维费用就够养一个小团队了。所以 Oracle 只适合数据绝对不能丢、业务必须强一致的场景，比如金融交易、核心账务。创业公司千万别碰，一个授权就能让你破产。
PostgreSQL 这几年突然火起来，很多人说它是开源界的 Oracle。这话不假，PG 对 SQL 标准的遵从度极高，支持 JSONB、全文检索、地理空间数据等高级功能，而且扩展性特别好，插个插件就能变成时序数据库或图数据库。但 PG 有个致命问题：生态圈不如 MySQL 成熟。比如中间件、监控工具、运维平台，MySQL 那边有一大堆现成的，PG 这边很多都得自己折腾。而且 PG 的内存管理机制比较复杂，配置不当很容易出现性能瓶颈。我见过一个团队用 PG 做日志分析，结果因为 work_mem 设置太小，频繁触发磁盘排序，查询慢得像蜗牛。PG 适合需要复杂查询和高级数据类型的场景，比如数据分析平台、GIS 应用、金融风控系统。但要做好心理准备，运维人员得有两把刷子。
MongoDB 这个文档型数据库在互联网圈子里也挺常见。它的最大优势是灵活，你不用事先定义表结构，想存什么字段就存什么字段，开发效率极高。而且它对高并发写入的支持比 MySQL 好得多，水平扩展也简单，直接加节点就行。但 MongoDB 的坑也不少。默认的事务隔离级别很弱，两个客户端同时修改同一条文档时可能会出现数据覆盖。而且它的内存占用非常大，基本是能占多少就占多少，服务器内存小了根本跑不动。更烦人的是，它的查询语法跟 SQL 完全不同，开发人员得重新学一套。我有个朋友的公司用 MongoDB 做用户行为追踪，结果一到月底报表就慢得吐血，因为聚合管道的性能实在堪忧。MongoDB 适合数据结构频繁变化、写入量大、查询模式简单的场景，比如物联网数据采集、实时日志、内容管理。但千万别拿它做核心交易系统，会出大事。
Redis，严格来说它不算传统意义上的数据库，更多是缓存中间件。但架不住好用啊，内存读写速度是毫秒级的，做热点数据缓存或者计数器简直不要太爽。Redis 支持的数据结构特别丰富，字符串、哈希、列表、集合、有序集合，每个都有独特用途。不过 Redis 的短板也很明显：数据全在内存里，一旦断电，未持久化的数据就全没了。虽然它支持 RDB 和 AOF 两种持久化方式，但性能会打折。而且 Redis 的单线程模型意味着它只能用一个 CPU 核心，计算密集型任务做不了。我见过一个公司把用户会话全放 Redis 里，结果一次机器宕机，所有用户都得重新登录，被骂得狗血淋头。Redis 适合做缓存、计数器、消息队列、实时排行榜，但千万别把它当成永久的存储系统。
SQLite 这个轻量级数据库被很多人忽视了。它不需要安装，不需要配置，直接一个文件就能用，特别适合移动端 App、嵌入式设备或单机工具软件。SQLite 的稳定性相当高，测试覆盖度比很多商业数据库都强。但它的并发能力极差，只支持一个写入者，多个读取者勉强能行。而且它不支持网络访问，不能做分布式部署。我有个朋友做了一款桌面软件，用户量一上来，SQLite 的并发写入就扛不住，只能改成 MySQL。所以 SQLite 只适合单用户或低并发场景，比如手机 App 本地存储、IoT 设备数据缓存。要是做 SaaS 服务，趁早别用。
说下 TiDB，这是国产数据库里的一匹黑马。它兼容 MySQL 协议，支持水平扩展、自动分片，还能做到强一致性分布式事务。对于业务增长快、数据量大的场景，TiDB 能省去很多分库分表的心。但 TiDB 的缺点是部署和维护复杂，需要至少三台机器做集群，而且版本升级时容易出现兼容性问题。它在 OLTP 场景下性能还算不错，但 OLAP 查询就一般了，需要搭配 TiFlash 才能凑合。我见过一个公司用 TiDB 做订单系统，刚开始还挺爽，后来数据量到十几 TB 时，GC（垃圾回收）导致查询延迟飙升，调了半天才稳定下来。TiDB 适合需要水平扩展但又不想改业务的场景，比如电商订单、社交动态、金融账务。但团队里必须有懂分布式系统的人，不然出问题根本搞不定。
说了这么多，其实选数据库就三个原则：第一，搞清楚业务的核心需求是啥。是要求数据绝对一致，还是追求高并发写入？是查询复杂多变，还是简单粗暴？第二，别盲目追新。那些吹得天花乱坠的数据库，很多只适合特定场景，拿来通用就是给自己挖坑。第三，考虑团队能力。再牛的数据库，没有合适的人运维，早晚出问题。MySQL 之所以这么流行，很大程度上是因为 DBA 好找，生态成熟。你非要上个冷门数据库，招人都费劲。
我的建议是，大部分普通业务场景，MySQL 加 Redis 基本够用了。如果数据量实在大到离谱，再考虑 TiDB 或者其他分布式方案。金融和电信这种强一致场景，老老实实上 Oracle 或 PostgreSQL。移动端和嵌入式就选 SQLite。别纠结，别跟风，选自己最熟悉的，往往比什么都强。
