查询解析方案选型，别只看功能清单

查询解析方案选型别只看功能清单MySQL 解析器选型先看业务实际 SQL而不是功能列表。网关、审计和改写场景通常还要考虑版本跟进、错误位置、AST 可修改性、内存行为和许可证这些问题在接入后比“能否解析一条示例 SQL”更容易出成本。建立项目自己的兼容样本从线上脱敏日志和迁移脚本中抽取语句保留 DDL、CTE、窗口函数、JSON、注释、预处理参数和异常输入。每次升级解析器都跑同一批样本比较成功与失败、AST 摘要和报错位置。MySQL 方言版本需在依赖清单中明确不要用“全面兼容”描述。评估四类成本吞吐和分配用目标语言、真实语句长度和并发测试而不是引用第三方跑分。维护确认上游是否持续支持所需版本与安全修复。改写检查 AST visitor、格式化输出和保留注释的能力改写后必须重新解析或校验。集成原生源码、Go 库和 Java 关系代数工具的进程模型、许可证和部署复杂度不同。Vitess、TiDB、MySQL 源码中的解析器以及 Calcite 各有适用位置。前两者更常用于 Go 生态的网关或工具直接复用 MySQL 源码会带来版本绑定Calcite 更适合需要关系代数转换的服务。具体结论仍应由样本集和目标版本验证。最小落地路径先只解析和分类记录不支持语法再引入只读 SQL 的标注或审计。需要重写时把改写规则做成可关闭、可测试的独立层并提供原 SQL、改写 SQL、解析版本和拒绝原因的审计记录。不要让解析器替业务猜测意图。