为什么 EXPLAIN 看不到真实的 SQL 执行耗时
许多开发者习惯使用 EXPLAIN 命令来分析慢查询，但结果常常令人费解：执行计划看起来完美，实际运行却异常缓慢。根本原因在于，EXPLAIN 展示的只是一个由优化器生成的“预估”查询计划，它并不真正执行 SQL 语句，因此无法统计那些导致性能下降的实际开销——例如磁盘 I/O 操作、锁竞争等待，或是多版本并发控制（MVCC）带来的额外负担。
EXPLAIN 仅显示预估执行计划，不进行实际查询，因此无法反映磁盘I/O、锁等待、MVCC开销等真实耗时；需要结合 performance_schema、慢查询日志分析以及 sys 系统库视图来准确定位性能瓶颈。
简单来说，你看到的 type=ref（索引引用）或 rows=100（预估行数）都只是优化器的理论推测，并非实际测量结果。真正的性能瓶颈往往隐藏在计划之外：可能是大字段（如 TEXT、BLOB）的传输拖慢了网络，临时表写入磁盘导致 I/O 激增，排序操作超出了内存限制，或者查询被其他长事务阻塞。此时若只依赖 EXPLAIN，很容易得出“索引已命中，查询应高效”的错误结论，从而错过真正的优化机会。
- 要全面诊断性能问题，必须借助更多工具。例如，使用
SELECT ... INTO DUMPFILE实际执行并观察资源消耗，或者利用 MySQL 5.7 及以上版本提供的performance_schema（已取代旧的SHOW PROFILE）来精确测量各执行阶段的耗时。 - 开启慢查询日志的
log_queries_not_using_indexes=ON参数也有助于发现未走索引的查询，但需注意，它无法捕获“虽然使用了索引但依然执行缓慢”的语句。 - 尤其需要警惕
ORDER BY ... LIMIT这类场景。EXPLAIN预估的rows值常常远低于实际。这是因为优化器基于索引顺序进行成本估算，但实际执行时，为了找到符合 MVCC 可见性条件的行，可能需要跳过大量已标记删除的记录，这部分开销并未计入预估成本。
如何利用 sys.schema_table_statistics_with_buffer 快速定位数据库热点表
当数据库整体性能下降时，快速找出拖慢系统的表是关键。MySQL 5.7 及以上版本内置的 sys 系统库是一个性能诊断宝库，其中的 schema_table_statistics_with_buffer 视图堪称快速定位热点表的“神器”。它巧妙地将表级访问统计（来自 information_schema.TABLE_STATISTICS）与 InnoDB 缓冲池的使用情况相结合，直接帮你找出那些“被频繁读取却又难以在内存中驻留”的性能瓶颈表。
无需再手动计算全局的 innodb_buffer_pool_read_requests 与 innodb_buffer_pool_reads 比率，那个整体指标很容易掩盖个别表的严重访问不均。
- 想找出物理 I/O 读取最高的前 5 张表？一条 SQL 即可搞定：
SELECT * FROM sys.schema_table_statistics_with_buffer ORDER BY ios_by_read DESC LIMIT 5;
- 如果发现某张表同时满足
buffer_pool_pages_dirty > 0（存在脏页）且ios_by_read（物理读取 I/O 次数）很高，就需要高度关注。这通常意味着该表正陷入“频繁修改产生脏页”与“频繁读取需要缓冲”的恶性循环，导致缓冲池效率低下。 - 请注意：该视图默认仅统计 InnoDB 引擎表。若系统中存在 MyISAM 表，需单独查询
information_schema.TABLES视图以获取其DATA_LENGTH和INDEX_LENGTH等大小信息。
pt-query-digest 分析慢日志时为何会遗漏 Prepared Statement
pt-query-digest 是分析 MySQL 慢查询日志的强大工具，但在分析使用预处理语句（Prepared Statement）的应用程序时，可能会“丢失”部分关键数据。根源在于 MySQL 的慢日志记录机制：它记录的是原始的 SQL 文本。对于一条预处理语句，日志会将其拆分为独立的 Prepare（准备）和 Execute（执行）两条记录。pt-query-digest 默认通常只聚合分析 Execute 部分，但核心问题在于，绑定具体参数后的实际执行计划，可能与 Prepare 阶段生成的通用计划截然不同。
情况可能更复杂：如果应用程序使用 mysql_stmt_execute() 并设置了 query_cache_type=DEMAND，慢查询日志甚至可能完全不会记录该语句的执行，导致分析无从下手。
- 在使用
pt-query-digest进行深度分析前，建议先用mysqldumpslow -s t命令快速扫描日志，确认是否存在大量Prepare后跟随不同参数Execute的模式。 - 可以尝试使用命令
pt-query-digest --filter '$event->{fingerprint} =~ m/^\s*execute/i' slow.log强制只分析Execute记录，但这仍无法解决因参数绑定导致的执行计划差异问题。 - 对于 MySQL 8.0 及以上版本的用户，更推荐的方法是直接利用
performance_schema。开启performance_schema.events_statements_history_long记录，然后通过查询sys.statement_analysis视图进行分析。它能还原绑定参数后的完整 SQL 指纹，提供更精确的性能画像。
可视化监控中，innodb_buffer_pool_pages_data 骤降不等于内存不足
在进行数据库监控告警或可视化性能分析时，若发现 innodb_buffer_pool_pages_data（缓冲池中存有数据的页数）指标突然大幅下降，很多人的第一反应是“内存不足，MySQL 正在频繁刷脏页”。但实际上，这个现象可能指向完全不同的原因。
更常见的情况是：有数据表被执行了 DROP 或 TRUNCATE 操作，或者 Buffer Pool 正在在线调整大小（通过 SET GLOBAL innodb_buffer_pool_size）。尤其是在 Kubernetes 等容器化环境中，如果为 Pod 设置的内存限制（limit）过于苛刻，一旦触发 Linux OOM Killer，整个 mysqld 进程被杀死后重启，pages_data 指标自然会归零——但这完全是进程级别的崩溃重启所致，与 Buffer Pool 本身的配置或负载压力无关。
- 不要急于下结论。首先查询
SHOW ENGINE INNODB STATUS\G命令输出中的BUFFER POOL AND MEMORY部分，对比Database pages（数据库页）和Free buffers（空闲缓冲）这两个值是否同步下降。 - 检查
information_schema.INNODB_METRICS表，查看buffer_pool_resize_status指标是否为 1，这表示 Buffer Pool 正在调整大小。 - 查阅系统日志（如
/var/log/syslog或/var/log/messages），搜索“out of memory”等关键字，确认是否发生了 OOM 事件，而不是仅仅盯着 MySQL 内部指标猜测。
那么，什么才是 Buffer Pool 面临真实内存压力的可靠信号呢？关键在于另外两个指标：如果 innodb_buffer_pool_wait_free（等待空闲缓冲页的次数）持续增长，说明确实有线程在等待可用内存页；如果 innodb_buffer_pool_read_ahead_evicted（预读页刚加载就被驱逐的次数）突然大幅增加，那更是典型的缓存抖动（Cache Thrashing）信号，表明缓冲池可能太小，或者工作负载的访问模式过于随机，导致预读机制失效。
