企业官网建设流程全解析

• 开发工具
• 数据库

soar（SQL Optimizer And Rewriter）是一款面向 MySQL 的 SQL 智能优化与改写工具。本文基于仓库 doc/roadmap.md 官方路线图，逐一解读项目在语法解析、环境支撑、诊断能力、线上执行与编辑器生态五个维度的规划与现状，并结合 ast/tidb.go、ast/vitess.go、database/profiling.go、database/trace.go 等源码给出实现级印证，帮助读者理解 soar 的能力边界与演进方向。

语法支持：依赖 Vitess 与 TiDB 双解析引擎

路线图第一条明确了 soar 的语法解析策略——主要依赖 vitess 与 TiDB 对 SQL 语法的支持，这是 soar 整个功能链条的最底层基石。

在源码层面，这一策略体现为ast包下的双解析引擎设计：

• ast/tidb.go 中的TiParse函数封装了github.com/pingcap/parser（TiDB 解析器），提供PrintPrettyStmtNode（打印语法树）与StmtNode2JSON（输出 AST 的 JSON 结构）两个核心能力，并实现SchemaMetaInfo从 SQL 中提取库表元信息；
• ast/vitess.go 中的PrintPrettyVitessStmtNode与VitessStmtNode2JSON则基于vitess.io/vitess/go/vt/sqlparser实现同类能力，两套引擎输出的 AST 均可序列化为 JSON，供上层规则分析消费。

值得注意的是，TiDB 解析器并非能解析全部 MySQL 方言。为了提升兼容性，TiParse内部通过removeIncompatibleWords对 SQL 做了预处理（见 ast/tidb.go）：移除ON UPDATE CASCADE、剔除/*!5开头的版本化注释、去掉CHARACTER SET声明、将CREATE TEMPORARY TABLE归一化为CREATE TABLE等，以绕过 pingcap/parser 暂不支持的部分语法。此外，遇到Unknown character set错误时也会做容错处理（ast/tidb.go）。

适用范围：当前仅针对 MySQL 语法族开发与测试

路线图明确指出：目前仅针对 MySQL 语法族进行开发和测试，其他使用 SQL 的数据库产品暂不支持。

这一边界贯穿整个项目：

• 数据库驱动层使用github.com/go-sql-driver/mysql（见 common/config.go），面向 MySQL 协议；
• 优化建议、重写规则、EXPLAIN 分析（ExplainType、ExplainFormat等配置项）均以 MySQL 执行计划语义为基础（见 common/config.go）；
• 采样、Profiling、Trace 均直接使用 MySQL 会话级指令（详见下文）。

因此，读者在使用 soar 时应将其视为MySQL 专用工具：PostgreSQL、Oracle、SQL Server 等方言暂不在支持范围之内，相关兼容诉求只能等待项目后续扩展。

Profiling 与 Trace：面向资深 DBA 的诊断能力深化

路线图第三条指出：Profiling 和 Trace 功能有待深入挖掘，供经验丰富的 DBA 分析使用。这说明两项能力已具备雏形，但定位为进阶诊断手段，仍需后续打磨。

Profiling：基于 SHOW PROFILE 的耗时分解

实现位于 database/profiling.go，核心逻辑为：

1. 通过sqlparser.Preview只允许SELECT、UPDATE、DELETE三类语句参与分析；
2. 开启事务并执行set @@profiling=1；
3. 实际执行 SQL 后执行show profile读取各执行阶段耗时；
4. 最后以set @@profiling=0关闭并回滚事务。

结果通过FormatProfiling格式化为 Markdown 表格（| Status | Duration |，见 database/profiling.go），方便 DBA 直接定位耗时瓶颈阶段。

Trace：基于 OPTIMIZER_TRACE 的优化器行为还原

实现位于 database/trace.go，逻辑与 Profiling 类似，但额外做了两层前置校验：

• 要求测试环境 MySQL 版本不低于 5.6（Version < 50600直接报错，见 database/trace.go），因为OPTIMIZER_TRACE自 5.6 才可用；
• 对SELECT/UPDATE/DELETE自动拼接explain前缀，再开启SET SESSION OPTIMIZER_TRACE='enabled=on'执行，最后从information_schema.OPTIMIZER_TRACE读取完整的优化器决策轨迹。

FormatTrace会将原始 SQL 与 JSON 格式的 Trace 内容以代码块形式输出（database/trace.go），呈现"输入 SQL → 优化器完整决策链"的原始证据。

安全护栏：白名单防误操作

无论是 Profiling 还是 Trace，都在执行前检查"当前连接地址是否与测试环境一致"，不一致时调用dangerousQuery进行 SQL 白名单校验，拒绝危险语句（见 database/profiling.go 与 database/trace.go，底层实现在 database/mysql.go）。这一机制确保诊断能力不会成为误操作线上库的入口。

两项能力的开关均受common.Config控制：Profiling、Trace配置项（common/config.go），并在数据采样开启时对测试环境执行。

线上自动执行与数据备份：明确暂不支持

路线图指出：目前尚不支持直接线上自动执行评审通过的 SQL，后续会努力支持，且由于暂不支持线上自动执行，数据备份功能也未提供。

这两条红线与 soar 的产品定位一致——soar 是评审器与改写器，而非变更执行器。从配置结构看，common/config.go 中的OnlineDSN与TestDSN分工明确：线上库用于拉取采样数据，测试库用于验证执行；DryRun（预演模式）默认开启（common/config.go），强调"先评审、后人工决策"的工作流。仓库中也未发现任何与数据备份相关的配置项或模块（如backup关键字在 common/config.go 中无匹配），印证了路线图的表述。

对使用者的启示是：评审通过 ≠ 自动上线。生产环境的变更执行仍须由 DBA 人工审核并借助变更流程平台完成，soar 的输出（优化建议、改写后的 SQL、Explain 报告）作为决策依据。

编辑器插件：Vim / Sublime / Emacs 生态

路线图将Vim、Sublime、Emacs 等编辑器插件支持列入规划。目前仓库中已落地 Vim 插件：

• 插件文件位于 doc/example/soar.vim；
• 完整安装步骤记录于 doc/editor_plugin.md：先安装 Syntastic，将soar.vim拷贝至syntax_checkers/sql目录，再在registry.vim中注册'sql':['soar', 'sqlint']检查器，即可在 Vim 中实时对 SQL 进行 soar 评审。

该功能的应用价值在于：将 SQL 评审从"命令行提交"延伸到"编码现场"，在编写 SQL 的当下即时获得优化建议。

多语言支持：中文建议为主，欢迎社区贡献

路线图最后一条明确：目前只支持中文优化建议，欢迎协助增加多语言支持。

这是项目当前的语言边界：评审规则、提示文案以中文呈现，面向中文开发者。多语言（如英文）建议的落地依赖国际社区的贡献。读者可关注仓库中规则定义与提示文本的分布位置（如 advisor/rules.go）作为潜在改造起点，若参与贡献可遵循 CONTRIBUTING.md 的规范。

小结：路线图视角下的 soar 能力地图

综合 doc/roadmap.md 与仓库源码，可以勾勒出 soar 的清晰定位与演进脉络：

对于使用者而言，这份路线图意味着：soar 当下最适合作为 MySQL 场景下的"SQL 评审 + 改写 + 深度诊断"工具链一环，配合 DBA 人工把关使用；而对计划二次开发或贡献代码的开发者，路线图则指出了项目最期待被补齐的短板——线上自动执行、备份能力、多语言建议，以及更深度的 Profiling/Trace 分析。

• 开发工具
• 数据库