根本原因是统计信息过期或缺失导致优化器误判数据分布，叠加隐式转换、连接顺序错误、缓冲区配置差异及长尾效应等多重因素。
为什么 EXPLAIN 在生产环境显示走了索引，但实际还是慢
根本原因往往是统计信息过期或缺失，导致优化器误判数据分布。开发库数据量小、分布均匀，ANALYZE TABLE 后生成的统计信息“碰巧”准确；而生产库中某张表的某个字段存在严重倾斜（比如 95% 的 status = 'pending'），优化器却仍按“均匀分布”估算，结果选了走 status 索引再回表，而不是走更高效的联合索引或主键扫描。
实操建议：
- 检查统计信息是否更新：
SELECT table_name, update_time, table_rows FROM information_schema.tables WHERE table_schema = 'your_db' AND table_name = 'your_table';—— 注意table_rows是估算值，不代表真实行数 - 强制刷新统计：
ANALYZE TABLE your_table;（MySQL）或ANALYZE your_table;（PostgreSQL）；对大表加WITH (VERBOSE)观察采样过程 - 避免依赖自动统计：MySQL 8.0+ 默认开启
innodb_stats_auto_recalc，但仅在 10% 行变更时触发，线上高频更新场景下常滞后
关联字段类型不一致导致隐式转换，索引失效
开发环境可能用 VARCHAR(32) 存 ID，生产环境却是 BIGINT；或者两边字符集不同（utf8mb4 vs latin1）。此时即使写了 ON a.id = b.user_id，MySQL 也会把 b.user_id 转成字符串做比较，导致 b 表上的索引完全无法使用。
实操建议：
- 用
SHOW CREATE TABLE对比开发与生产两张表的字段定义，重点核对：data_type、collation、is_nullable - 在
EXPLAIN结果里看type列：如果是ALL或index（而非ref/eq_ref），再查Extra是否含Using where; Using join buffer，基本可断定发生了隐式转换 - 显式统一类型：
ON a.id = CAST(b.user_id AS SIGNED)（临时修复），但长期必须改表结构
连接顺序被优化器错误选择，小表没驱动大表
MySQL 5.7 及以前默认使用嵌套循环（NLJ），优化器会基于“预估行数”决定驱动表。如果统计不准，它可能选错：拿百万级表当驱动表，对每行去关联千万级表，哪怕有索引也扛不住 IO 和 CPU 开销。
实操建议：
- 用
EXPLAIN FORMAT=TRADITIONAL查看select_type和table顺序，确认哪张是驱动表；结合rows列判断预估是否离谱 - 用
STRAIGHT_JOIN强制连接顺序（仅限 MySQL）：SELECT /*+ STRAIGHT_JOIN */ ... FROM small_table s STRAIGHT_JOIN big_table b ON s.id = b.small_id; - 注意：PostgreSQL 使用动态规划选路径，
enable_hashjoin=off等开关只影响算法，不改变驱动逻辑；真正要控序得靠子查询物化或 CTE 加MATERIALIZED
生产环境的缓冲区配置让执行计划“变味”
开发机 sort_buffer_size 设得大，ORDER BY + LIMIT 关联查询能走 filesort 内存排序；但生产库为防内存溢出调小了该值，导致大量磁盘临时文件，IO 拖垮整体速度。类似地，join_buffer_size 不足时，NLJ 会退化成块嵌套循环（BNL），甚至触发磁盘 join buffer。
实操建议：
- 对比
SHOW VARIABLES LIKE '%buffer%';中关键项：sort_buffer_size、join_buffer_size、read_buffer_size—— 开发环境常设为 2M~8M，生产环境可能只有 256K - 不要全局调高：这些 buffer 是 per-connection 分配的，盲目放大反而引发 OOM；应针对慢查询 Session 级调整：
SET SESSION sort_buffer_size = 4194304; - 监控临时表使用：
SHOW GLOBAL STATUS LIKE 'Created_tmp%';，若Created_tmp_disk_tables持续上升，说明排序/分组已落到磁盘
最常被忽略的一点：生产数据的“长尾效应”。比如订单表里 99% 的订单创建于最近 7 天，但关联用户表时，优化器按全表统计估算 user_id IN (…) 的匹配率，完全没考虑时间局部性。这种分布偏差，光靠 ANALYZE 解决不了，得靠直方图（MySQL 8.0+ ANALYZE TABLE … WITH HISTOGRAM ON (user_id)）或业务层加时间范围过滤兜底。
