根本原因是统计信息过期，优化器仍按旧行数估算执行计划；空表不触发自动更新，需手动analyze table刷新n_rows并确认innodb_stats_persistent=on。

EXPLAIN 显示全表扫描，但表明明是空的

空表上 SELECT * FROM t1 JOIN t2 ON t1.id = t2.t1_id 却要耗几百毫秒，EXPLAIN 却显示 type=ALL、rows 估数几万——这说明优化器没信“空”这个事实。根本原因常是统计信息过期：INFORMATION_SCHEMA.STATISTICS 或 mysql.innodb_table_stats 里存的行数、索引基数仍是旧值，哪怕你刚 TRUNCATE TABLE 过。

MySQL 8.0+ 中统计信息自动更新不可靠的场景

MySQL 默认开启 innodb_stats_auto_recalc=ON，但只在表数据变更超 10% 且行数 ≥ 25 非临时表时触发。空表（0 行）永远不满足“变更 10%”，所以统计信息卡在 truncate 前的状态；同样，小表（比如只有 20 行）删掉 15 行后也大概率不刷新。结果就是优化器按“老胖子”估算执行计划，选错驱动表、误判索引有效性。

• 用 SHOW TABLE STATUS LIKE 't2' 查 Rows 字段，若远大于 0，基本可判定统计信息滞后
• ANALYZE TABLE t2 是最直接的修复手段，强制重采样（注意：会加 MDL 读锁，大表慎用）
• 对频繁清空又重载的小表，建议在 TRUNCATE 后紧跟 ANALYZE TABLE，别依赖自动

JOIN 顺序被错误估算导致空表也慢

当优化器以为 t2 有 50000 行，就会把它当小表去驱动 t1，实际却因 t2 为空，整个嵌套循环一次都不进——但代价已经付出了：打开表、初始化 join buffer、尝试读取第一行……这些开销叠加起来，比预期高得多。更麻烦的是，如果 t2 上有低选择性索引（比如 status 列只有 2 个值），优化器还可能放弃走索引而回退到全表扫描逻辑。

• 用 EXPLAIN FORMAT=TREE（MySQL 8.0.16+）看实际选择的驱动表和访问方法
• 显式用 STRAIGHT_JOIN 强制驱动顺序，比如 SELECT STRAIGHT_JOIN ... FROM t1 JOIN t2，让 t1 当驱动表（前提是 t1 确实非空且有合适索引）
• 检查 t2.t1_id 是否有索引：没索引时，即使 t2 为空，MySQL 仍需打开并检查结构，延迟更明显

为什么 ANALYZE TABLE 有时也不管用

ANALYZE TABLE 在某些配置下会失效：比如 innodb_stats_persistent=OFF（老版本默认），此时统计信息只存在内存，重启就丢；或者 innodb_stats_method=nulls_unequal 导致对含大量 NULL 的列估算严重失真。另外，分区表、临时表、或使用了 CREATE TABLE ... SELECT 创建的表，其统计信息更新行为也和普通表不同。

• 确认持久化开关：SELECT @@innodb_stats_persistent，应为 ON
• 查当前采样页数：SELECT * FROM mysql.innodb_table_stats WHERE database_name='db' AND table_name='t2'，关注 n_rows 和 last_update
• 极端情况可手动更新：UPDATE mysql.innodb_table_stats SET n_rows=0, last_update=NOW() WHERE ...，但需 FLUSH TABLES 生效，且仅限紧急排查

真实慢的原因往往不是“空”，而是“优化器不信它是空”。统计信息滞后是静默型故障，不报错、不告警，只悄悄拖慢查询。只要涉及定期清空+重载的表，就把 ANALYZE TABLE 当成清理流程的最后一步，而不是可选项。