为何SQL数据库与ORM/查询构建器仅通过SQL具体语法通信？

历史层面的核心原因 #

• 路径依赖焊死了生态：SQL从上世纪70年代诞生后，很快成为数据库领域的通用标准。几十年下来，所有应用、工具、教程甚至开发者的思维模式都围绕SQL构建。现在要换用新协议，企业得重构大量代码，开发者得重新学习整套逻辑，迁移成本高到几乎没人愿意尝试。
• 早期没有催生替代方案的刚需：早年数据库的数据量和查询复杂度都很低，文本SQL带来的解析、传输开销完全可以忽略。SQL注入问题也是Web应用普及后才凸显的，而那时ORM已经通过参数化查询解决了大部分风险，进一步降低了替换底层协议的动力。

技术层面的现实障碍 #

• SQL的通用性难以替代：SQL是声明式语言，一套语法就能覆盖联表、聚合、复杂子查询等绝大多数关系型数据库的查询需求。要设计一套二进制协议，得把所有这些场景都抽象成二进制格式，难度极大，根本做不到SQL的灵活性和通用性。
• 二进制协议搞不定跨库兼容：不同数据库的存储引擎、数据类型、查询优化逻辑差异巨大，想做一个通吃所有数据库的通用二进制协议基本不可能。但SQL作为文本协议，哪怕各家有方言，核心语法仍能通用，这是二进制协议没法比的优势。
• 文本SQL的调试成本极低：写出来的SQL语句能直接被人阅读、修改，排查问题时一目了然。要是用二进制协议，必须依赖专门工具解析才能知道请求内容，调试成本飙升，开发者根本不买账。
• 现有优化手段已抹平文本劣势：数据库厂商早就通过预编译语句、连接池、查询缓存等机制，把文本SQL的解析开销压到了很低的水平。参数化查询既解决了SQL注入问题，还能让数据库复用执行计划，使得替换协议的性价比极低——费大力气折腾，收益却微乎其微。

内容的提问来源于stack exchange，提问作者Danilo Mendes