数据库解析器改造，先从一条脱敏查询开始

数据库解析器改造，先从一条脱敏查询开始

解析器扩展应从一个可测的需求开始，例如识别一类受控 Hint 或拒绝超出规范的语句，而不是直接做“智能 SQL 改写”。范围越小，越容易看清语法、权限、参数绑定和执行计划之间的关系。

最小路径

如果引入 AI，它只返回结构化建议，例如候选 Hint、风险标签或需要人工复核的理由。建议必须经过 AST 级白名单校验，不能把模型输出或外部输入直接拼接为 SQL。无建议、校验失败和模型超时都应保持原 SQL 语义。

先写测试再扩语法

测试集至少包括合法/非法语句、嵌套表达式、预处理参数、不同字符集、权限边界和复制回放。对每个接受的改写，比较结果集与执行计划摘要；写语句还要检查 binlog 与副本结果。生产样本须脱敏，且不应将账号、参数或业务文本写进测试仓库。

bool allowed_hint(const Hint& hint) { return hint.type == HintType::UseIndex || hint.type == HintType::MaxExecutionTime; }

目标 MySQL 分支的 AST 和内存 API 不相同，示例不应直接复制。先复用该版本已有的节点构造、错误报告与内存生命周期模式，再加入新逻辑。

交付标准

一个可交付的 MVP 要有开关、审计摘要、明确错误码和回退路径。先在离线 SQL 集和影子流量中验证，再逐步启用；出现无法解释的解析差异或计划退化时，关闭扩展而非继续放量。