mysql不提供标准ast接口，唯一接近的是explain format=tree输出的逻辑执行树；它反映解析后、优化前的查询结构，但非真正ast，且需合法sql、避开动态语句与权限问题。
MySQL 不提供直接导出或查看标准 AST 的接口，也没有类似 PostgreSQL 的 pg_get_querydef() 或 JSON AST 输出能力。你真正能拿到的、最接近 AST 的结构，是 EXPLAIN FORMAT=TREE 的输出结果——但它不是 AST，而是优化前的逻辑执行树。
EXPLAIN FORMAT=TREE 是唯一可用的“类AST”视图
MySQL 8.0+ 支持该语法，它展示的是解析 + 预处理后、尚未进入优化器重写阶段的查询结构，节点类型（SELECT、TABLE_SCAN、INDEX_RANGE_SCAN、WHERE）和嵌套关系基本反映原始语法层级。
- 必须对合法可执行的 SQL 运行；语法错误会直接报错，不输出树
- 避免含用户变量（如
@var）、存储过程逻辑、PREPARE/EXECUTE 动态语句，否则树中会出现不可预测的封装节点 - 字符集、注释、大小写、空格等被忽略，符合 AST “忽略冗余细节” 特性
- 示例：
EXPLAIN FORMAT=TREE SELECT a.id FROM t1 a JOIN t2 b ON a.id = b.t1_id WHERE b.status = 'active';
为什么不能用 SHOW WARNINGS / performance_schema 查 AST
常见误操作包括查 SHOW WARNINGS、翻 performance_schema 表、甚至试图从慢日志还原结构——这些路径全部无效。
-
SHOW WARNINGS只返回解析/优化阶段的提示或警告文本，不含树形结构 -
performance_schema中没有名为ast_nodes、parse_tree等的表；相关表（如events_statements_*）只存文本和摘要 - 二进制日志（
mysqlbinlog）和慢查询日志只记录原始 SQL 字符串或执行耗时，不保留任何语法结构信息
真要调试源码级 AST？得进 parse_sql() 和 Parse_tree_root
MySQL 内部 AST 是 C++ 对象图，由 Bison 生成的解析器产出，挂载在 THD::m_parser_state->m_parse_tree，类型为 Parse_tree_root。它不可序列化，也不对外暴露。
- 需编译带调试符号的 MySQL（
-DCMAKE_BUILD_TYPE=Debug），用 GDB 在parse_sql()返回前打断点 - 打印
thd->m_parser_state->m_parse_tree需配合源码理解字段含义，例如m_select_lex指向主 SELECT 节点，m_where_cond是条件表达式树根 -
mysqld --debug=d,parser和mysql --debug-info只打零散词法/语法分析日志（如shift token SELECT），无法还原树形结构 - 注意：AST 构建发生在权限检查之前，所以即使用户无表权限，只要 SQL 语法合法，
parse_sql()仍会成功构建 AST（但后续流程会中止）
替代方案：用 sqlglot 或其他外部解析器
如果你需要可编程、可导出、跨方言的 AST（比如做 SQL 改写、权限下推、规则校验），别硬啃 MySQL 源码。用 Python 生态的 sqlglot 更实际。
-
sqlglot.parse("SELECT a FROM t WHERE b > 1", dialect="mysql")返回标准 AST 对象，支持.sql(dialect="postgres")转换、.find(sqlglot.exp.Where)遍历节点 - 它能处理 MySQL 特有语法（如
INTO OUTFILE、分区剪枝表达式），且输出为纯 Python 对象，可json.dumps()导出 - 对比
sqlparse：后者只做分词和简单结构识别，不构建语义完整 AST；sqlglot才真正模拟了数据库级解析逻辑
真正卡住人的地方不是“怎么生成 AST”，而是误以为 MySQL 提供了标准接口。它没有。所有绕过源码的“查看 AST”尝试，最终都会落到 EXPLAIN FORMAT=TREE 这个折中产物上——它有用，但得清楚它不是 AST；它稳定，但得避开动态 SQL 和权限干扰；它可读，但不能当语法分析器 API 用。
