MySQL vs PostgreSQL：从技术选型、设计缺陷到打破行业规训的思考

你还记得第一次喝白酒的感觉吗？那股辛辣的液体划过喉咙，像一条火线灼烧食道。你的身体在用最原始的方式告诉你：这不是食物，这是毒药。 但旁人会说：习惯就好了。

审视MySQL时，你是否也有过类似的感受？当你深入了解，会发现它充满了令人费解的设计，仿佛在经历一次技术上的“服从测试”。

MySQL的设计“怪癖”

作为许多开发者的入门数据库，MySQL的一些默认行为和设计选择常常让人困惑：

• 字符集迷局：默认字符集是latin1，当你终于决定使用utf8时，会发现它并不支持完整的UTF-8（如emoji），真正的选择是utf8mb4。
• 时间戳的幽灵：TIMESTAMP类型存在2038年问题，像是一个尚未远去的“千年虫”。
• SQL标准服从度：GROUP BY子句可以选择非聚合列，这与SQL标准相悖。
• 类型别名：没有真正的布尔类型，BOOLEAN只是TINYINT(1)的别名。
• DDL操作风险：数据定义语言（DDL）不支持原子性事务，执行ALTER TABLE就像一场赌博。
• 复制与优化器：主从延迟是运维的常见痛点，而优化器的执行计划有时也令人难以捉摸。

你的技术直觉可能会发出警报：这不像深思熟虑的设计，更像是一系列历史遗留问题的集合。 相比之下，PostgreSQL的设计哲学更接近“理应如此”。但行业内的普遍反应往往是：习惯就好了。

规训是如何形成的

白酒文化并非自古有之，它是在特定权力结构中被塑造并自上而下传播的“规矩”。MySQL的流行路径与此惊人相似。

21世纪初，以硅谷为代表的互联网“权威”们普遍采用LAMP（Linux, Apache, MySQL, PHP）技术栈。这并非因为它是技术上的最优解，而是因为它免费、简单，且被成功者验证。当国内互联网巨头（BAT）也将MySQL定为标准后，这个选择便随着人才流动和行业影响力，扩散至整个中国互联网生态。

新一代程序员在“MySQL是互联网标配”的叙事中成长，鲜少有机会深入比较其他选项。质疑MySQL，有时就像在酒桌上拒绝白酒一样，会面临无形的压力。

技术选型中的“服从测试”

白酒在社交场合的一个核心功能是“服从测试”——测试你愿意为融入群体承受多少不适。

技术选型，尤其是数据库选型，在某些组织中也隐含着类似的逻辑。选择MySQL，往往意味着：

• 服从行业惯例，不挑战现状。
• 规避个人风险，避免因选择“非主流”技术而承担额外责任。
• 降低沟通成本，“行业标准”本身就是最有力的理由。

在许多场景下，提议使用PostgreSQL需要准备详尽的调研报告，并背负未来可能出现的所有问题。而选择MySQL则无需多言。规训的力量，在于它将服从变成了默认项，而将独立思考变成了需要额外付出成本的行为。

一个亲历者的反思

我曾在一家以Java和MySQL为主流的技术团队中，力排众议在一个项目里使用了PostgreSQL和Golang。整个过程阻力重重：需要反复论证、独自承担运维（DBA）职责、并承诺为所有潜在问题负责。

后来当我离开该项目，接手的同事第一时间就将技术栈切换回了Java和MySQL。原因无关技术优劣，仅仅是：换回主流选择，他就不再需要向任何人解释。 这让他回到了认知和责任的“安全区”。

这种经历促使我思考：是适应系统，还是寻找与自己技术理念契合的系统？这没有标准答案，但值得每个开发者深思。

MySQL作为技术的“吐真剂”

讨论数据库选型时，工程师的反应能揭示其深层的技术思维：

• “MySQL够用了”：可能意味着对“更好用的工具”缺乏体验，将忍受缺陷当作了常态。
• “大家都用MySQL”：表明决策依据更多是从众心理，而非独立的技术分析。
• “PostgreSQL学习成本高”：值得反思的是，我们是否将更多时间花在了学习MySQL各种“坑”的规避技巧上，而非掌握一个更一致的系统。
• “团队没人熟悉”：这可能暴露了团队在技术视野和投资上存在的问题。

有时，对PostgreSQL的严苛审视与对MySQL设计问题的宽容并存，这或许并非理性评估，而是出于保护自身已有知识投资的防御心理。

趋势正在转变

令人鼓舞的是，无论是酒桌文化还是技术选型，旧的“规训”都在松动。

在数据库领域，趋势已然明朗：

• 云原生推动：AWS Aurora、Google Cloud SQL、Azure Database等顶级云服务商都将PostgreSQL作为核心的托管数据库服务大力推广。
• AI时代的需求：PostgreSQL凭借pgvector等扩展，已成为处理向量嵌入、构建AI应用的首选数据库之一，而MySQL在此领域进展缓慢。
• 许可证与生态：PostgreSQL宽松的BSD许可证更受企业法务青睐；其开源生态的活跃度也远超MySQL。

各类权威调研数据（如DB-Engines排名、StackOverflow开发者调查）都一致显示，PostgreSQL是过去十年增长最快的数据库系统，正成为新一代创业公司和创新型项目的默认选择。

拥有选择的勇气

MySQL当然不是一个“不能用”的数据库，它在无数场景下稳定运行。关键在于区分“合适的选择”与“默认的选择”。

当下一次技术选型讨论开始时，当有人下意识地说“就用MySQL吧”，不妨多问一句：为什么？

我们是否花了太多时间学习如何规避一个系统的缺陷？我们那些所谓的“最佳实践”，有多少其实是在为不完美的设计打补丁？踩过的字符集坑、DDL锁表、主从延迟，有多少本是数据库层就该妥善解决的问题？

PostgreSQL并非完美，但它提供了一种可能性：一个设计上更注重一致性、正确性和开发者体验的系统。选择它，在中国互联网的特定语境下，依然需要一点勇气——打破惯性、独立判断、并为自己的选择负责的勇气。

这种勇气，与在酒桌上坦然说出“我喝不了酒”的勇气，本质相通：拒绝不假思索的服从，坚持基于理性的判断。