EXPLAIN ANALYZE会真实执行语句，触发读数据、加锁、I/O及临时表，必须避免在生产环境裸跑；安全做法是加WHERE限制或LIMIT、选从库/测试环境运行，并确认performance_schema已启用。
EXPLAIN ANALYZE 会真实执行语句，别在生产环境乱跑
它不是“看计划”，而是真读数据、真加锁、真触发磁盘 I/O 和临时表。对 UPDATE、DELETE、大结果集 SELECT 或高并发接口直接用，可能引发锁等待、慢查询雪崩甚至主从延迟。
安全做法：
- 先加限制：比如
WHERE id BETWEEN 1000 AND 1010或LIMIT 100 - 避开业务高峰；优先在从库或测试环境验证
- 确认
performance_schema已启用（否则无法关联历史行为）
怎么看出哪一步真正拖慢了查询
actual time 字段是核心——格式为 start..end（单位微秒），差值就是该节点耗时。注意它是**自底向上累加**的：最内层扫描的 end 是自身耗时；外层 Nested loop 的 end 包含所有子节点总耗时。
关键识别点：
- 若某节点
actual time=0.05..12000.00（约 12ms），而loops=1000，那单次均值仅 12μs，但总开销达 12ms —— 说明它被高频调用，应优先优化循环逻辑或连接条件 -
rows_examined远大于rows（预估行数）：统计信息过期，需ANALYZE TABLE -
Filter:行出现且rows显著下降：说明 WHERE 条件过滤效率低，考虑函数索引或重写条件
FORMAT=TREE 和 FORMAT=JSON 输出差异很实在
FORMAT=TREE（默认）适合人眼快速定位瓶颈层级，结构清晰；FORMAT=JSON 则包含完整嵌套关系、缓冲区使用、内存分配等元数据，适合脚本解析或压测比对。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
例如嵌套循环中想确认是否用了物化临时表，FORMAT=JSON 里会有 "materialized_from_subquery": true 字段；而 TREE 格式只显示 -> Materialize，无细节。
实用建议：
- 日常排查用
EXPLAIN ANALYZE FORMAT=TREE SELECT ... - 做自动化分析或对比不同索引效果时，必须用
FORMAT=JSON并提取execution_time、rows_examined等字段 - 避免依赖
cost_info：那是优化器估算值，和真实耗时不具可比性
为什么不能只靠 EXPLAIN ANALYZE 定位全部问题
它只反映 MySQL 引擎内部执行片段，不包含锁等待、网络传输、客户端处理、CPU 调度等外部开销。一次查询总耗时 800ms，EXPLAIN ANALYZE 显示 actual time 总和才 120ms，剩下近 700ms 就得查别的地方。
补全链路的关键动作：
- 查锁等待：
SELECT * FROM performance_schema.events_statements_history_long WHERE SQL_TEXT LIKE '%your_query%'，看LOCK_TIME字段 - 查网络与调度：用
slow_query_log配合long_query_time = 0，对比Query_time和EXPLAIN ANALYZE的actual time差值 - 查客户端瓶颈：比如 ORM 批量 fetch 太慢、JSON 序列化阻塞，这些
EXPLAIN ANALYZE完全看不到
真正难的不是看懂 actual time，而是意识到它只是冰山一角——漏掉外部环节，优化就永远浮在表面。
