优先用sqlformat命令行工具格式化慢查询SQL，MySQL 8.0+ JSON日志需先提取SQL字段再处理；EXPLAIN FORMAT=TREE配合\G查看嵌套执行计划；连接问题多因认证插件或时区不一致；格式化勿引入换行、注释或AS别名导致隐式转换或索引失效。
MySQL慢查询日志里SQL乱成一团，怎么快速格式化看懂？
直接用 mysqldumpslow 或 pt-query-digest 解析后，原始sql还是挤在一行里——这不是格式问题，是可读性断层。别手动换行，也别复制到在线美化器再粘回去，容易引入不可见字符或编码错乱。
- 优先用
mysql客户端自带的--verbose模式：执行mysql --verbose -u root -p -e "SELECT ..."，它会自动对输出的 SQL（比如 EXPLAIN 结果里的query_plan）做基础缩进 - 真正要格式化的是慢日志里抓出来的原始语句，推荐用
sqlformat命令行工具（Python 写的，pip install sqlparse后可用），执行sqlformat --reindent --keyword-case=upper input.sql - 注意：MySQL 8.0+ 的 JSON 格式慢日志（
log_output = 'TABLE,JSON'）需先用SELECT CAST(argument AS CHAR) FROM mysql.slow_log提取 SQL 字段，再喂给sqlformat，否则直接解析 JSON 文件会把引号和转义搞乱
EXPLAIN 输出太紧凑，怎么看清执行计划嵌套关系？
EXPLAIN FORMAT=TREE 是 MySQL 8.0 的关键改进，但很多人开了就以为“自动清晰了”，其实默认输出仍会折叠子节点，尤其遇到多层派生表或 CTE 时，缩进丢失、层级错位很常见。
- 必须加
\G终止符：比如EXPLAIN FORMAT=TREE SELECT * FROM t1 JOIN t2 ON ... \G，否则终端可能截断长行，导致缩进被压平 - 如果用程序调用（如 Python 的
mysql-connector），cursor.execute("EXPLAIN FORMAT=TREE ...")返回的是单字段字符串，需按\n分割后逐行判断前导空格数来还原层级，不能直接当 JSON 解析 - 老版本（
5.7及以前）没有FORMAT=TREE，只能靠EXPLAIN EXTENDED+SHOW WARNINGS看重写后的 SQL，但那不是执行计划结构，只是优化器改写结果，别混淆
可视化分析工具连不上 MySQL，到底是权限、协议还是时区坑？
TablePlus、DBeaver、甚至 mysqld_exporter 连接失败时，报错常是模糊的 Access denied 或 Connection refused，但真实原因往往藏在协议细节里。
- MySQL 8.0 默认认证插件是
caching_sha2_password，而很多旧版 GUI 工具只支持mysql_native_password；解决方法不是降级服务端，而是建用户时显式指定：CREATE USER 'dev'@'%' IDENTIFIED WITH mysql_native_password BY 'pwd'; - 时区不一致会导致慢日志时间戳和本地时间差 8 小时，误判“刚发生的慢查询”其实发生在昨天——检查
SELECT @@global.time_zone, @@session.time_zone;，并在连接串里加?serverTimezone=Asia/Shanghai - 可视化工具启用 Performance Schema 监控时，若看到
performance_schema.events_statements_summary_by_digest为空，大概率是performance_schema被禁用了（performance_schema=OFF在配置文件里），重启 mysqld 才生效，动态 SET 不起作用
SQL 格式化后性能反而变差？小心空格和注释触发的隐式强制转换
格式化本身不改变语义，但人工加的换行、空格、注释如果插在函数参数中间或类型声明附近，可能让优化器误判表达式结构。
- 例如把
WHERE created_at > DATE_SUB(NOW(), INTERVAL 7 DAY)格式化成多行后不小心写成：WHERE created_at > DATE_SUB(NOW(),\n INTERVAL 7 DAY)—— 某些低版本 MySQL（如 5.6.40）会因换行符解析失败，退化为全表扫描 - 在
IN列表里加注释（如WHERE id IN (1, /* admin */ 2, /* user */ 3)）看似无害，但 MySQL 5.7 对带注释的IN列表无法使用常量传播优化，可能导致索引失效 - 最隐蔽的是格式化工具自动补的
AS别名：比如把SELECT COUNT(*) t改成SELECT COUNT(*) AS t，看起来更规范，但如果后续 SQL 用到了这个别名做条件（如HAVING t > 100），而引擎版本不支持在HAVING中引用别名（如早期 MariaDB），就会报错
格式化和可视化只是放大镜，不是优化器本身；真正卡住性能的，往往是没看清 type 字段是不是 ALL，或者没注意到 key_len 比预期少了几个字节——这些细节，在花哨的图形界面里反而更容易被忽略。
