MySQL 索引未被使用根本原因是优化器评估全表扫描更快，常见于隐式类型转换、选择性骤降或统计信息过期；FORCE INDEX 仅在明确优化器误判且已验证时谨慎使用；ANALYZE TABLE 对大表或统计失真时有效，小表或自动分析已触发时则无效。
MySQL 为什么明明建了索引却不用 EXPLAIN 显示 type=ALL
根本原因不是索引没建，而是优化器评估后认为全表扫描比走索引更快——常见于条件组合后选择性骤降、隐式类型转换或统计信息过期。
典型诱因：WHERE status = '1' AND created_at > '2023-01-01' 中 status 是 TINYINT，但传了字符串，触发隐式转换，导致索引失效；或者 created_at 范围太大（比如查近一年），优化器估算走索引要回表太多次，不如直接扫。
- 用
SHOW INDEX FROM table_name确认索引字段顺序是否匹配查询条件前缀 - 用
SELECT COUNT(*) FROM table WHERE ……手动验证条件实际命中行数，和EXPLAIN的rows对比，偏差大说明统计不准 - 检查是否有函数包裹字段，如
WHERE DATE(created_at) = '2024-01-01'—— 这种一定不走索引
什么时候该用 FORCE INDEX，什么时候不该碰
FORCE INDEX 是手术刀，不是创可贴。它绕过优化器决策，强制走指定索引，适合你明确知道优化器误判且已验证该索引更优的场景。
但滥用会埋雷：当数据分布变化（比如某状态从 5% 变成 80%），原来最优的索引可能变成最差的，而 FORCE 会让问题静默恶化。
- 只在慢查询已定位到具体 SQL，且
EXPLAIN明确显示走了错误索引或没走索引时使用 - 必须配合
EXPLAIN FORMAT=JSON查看used_range_access和rows_examined_per_scan，确认强制后的执行路径确实更优 - 禁止在 ORM 自动生成的 SQL 上硬加
FORCE（比如 Django 的extra()或 SQLAlchemy 的with_hint()），这类写法极易随模型变更失效
ANALYZE TABLE 什么时候管用，什么时候白忙活
ANALYZE TABLE 重采样表的统计信息（如索引基数、数据分布直方图），对优化器选索引影响直接。但它不是万能解药。
例如：大宽表（50+ 列）、有大量重复值的字段（如 is_deleted）、或刚批量插入百万行但未触发自动分析时，ANALYZE 往往立竿见影；但若表本身很小（
- 执行前先查
information_schema.STATISTICS，看CARDINALITY是否明显失真（比如status只有 3 个值，但显示基数为 10000） - 生产环境避免在高峰期跑
ANALYZE TABLE，尤其 MySQL 5.7 及以前版本会锁表；8.0+ 默认是轻量级采样，但仍建议在低峰做 - 如果
ANALYZE后仍无效，优先怀疑是不是WHERE条件里用了OR、NOT IN或子查询，这些结构本身就会让优化器放弃索引
联合索引字段顺序怎么排才不被优化器“无视”
顺序不是按“常用程度”排，而是按“过滤强度 + 查询模式”定。优化器只用索引的最左前缀，所以第一个字段必须能高效过滤（高选择性），后续字段得匹配你的常见查询组合。
比如用户表常查 WHERE city = ? AND age BETWEEN ? AND ? ORDER BY created_at DESC，那么 (city, age, created_at) 比 (city, created_at, age) 更合理——因为 age 是范围查询，放在中间能继续用索引排序，而 created_at 放中间就断了索引利用链。
- 等值条件（
=、IN）字段放最左，范围条件（>、BETWEEN）放中间，排序 / 分组字段（ORDER BY、GROUP BY）放最后 - 避免把
is_deleted、status这类低基数字段放索引最左，除非 99% 查询都带这个条件且你确认优化器不会因此拒绝整个索引 - 用
SELECT DISTINCT验证字段顺序：如果SELECT city, age FROM user WHERE city = 'bj'走索引，但SELECT city, created_at FROM user WHERE city = 'bj'不走，大概率是created_at在索引里位置不对
最麻烦的不是不会加索引，而是索引存在却因统计滞后、隐式转换或联合顺序错位被悄悄弃用。线上查慢，先盯死 EXPLAIN 的 key 和 rows，再动手改，别靠猜。
