possible_keys 经常比 key 多，因为 possible_keys 是优化器评估出的所有可用索引候选，而 key 仅显示最终选定的一个；前者反映索引“能否用”，后者才说明“实际用了哪个”。
possible_keys 为什么经常比 key 多
possible_keys 是优化器“考虑过但没选上”的索引列表，它反映的是索引的可用性，不是实际使用情况。只要 WHERE、JOIN 或 ORDER BY 中涉及的字段上有索引，且该索引前缀能覆盖查询条件，就可能出现在 possible_keys 里。
常见误区是看到 possible_keys 不为空就以为索引被用了——其实 key 才是唯一可靠依据。比如 WHERE status = 'active' AND created_at > '2024-01-01'，表上有 idx_status 和 idx_status_created 两个索引，possible_keys 可能同时列出两者，但 key 只会是 idx_status_created（因为更优）。
- possible_keys 为空，说明没有索引能覆盖当前查询条件，大概率触发全表扫描
- possible_keys 有值但 key 为
NULL，说明优化器评估后认为走索引不如全表扫描快（例如查了 80% 的行） - possible_keys 和 key 相同，是理想状态；但 key_len 值偏小（比如只用到联合索引前半段），说明索引没被充分利用
key 为 NULL 到底意味着什么
key 为 NULL 表示这条执行计划中完全没走索引，等价于全表扫描（type = ALL）。但它不等于“没建索引”，而可能是以下任一原因：
- 查询条件未命中索引最左前缀（如对联合索引
(a,b,c)只写了WHERE b = 1） - 对索引字段用了函数或表达式（
WHERE YEAR(created_at) = 2024） - 隐式类型转换（
WHERE user_id = '123'，而 user_id 是 INT） - 优化器预估扫描行数太多，认为索引回表成本高于直接扫表
注意：key 为 NULL 时，rows 字段的估值往往非常大，这是第一手线索。
key_len 怎么帮你看清索引使用深度
key_len 显示 MySQL 实际用到的索引字节数，它不等于索引定义长度，而是由查询条件决定的“有效长度”。这个值能帮你确认是否只用了联合索引的一部分。
比如联合索引 idx_user_status_time(user_id, status, created_at)，其中 user_id 是 INT（4 字节），status 是 VARCHAR(20)（utf8mb4 下最多 80 字节），created_at 是 DATETIME（8 字节）。那么：
-
WHERE user_id = 100→ key_len ≈ 4（只用第一列） -
WHERE user_id = 100 AND status = 'done'→ key_len ≈ 4 + 80 + 1（+1 是变长字段长度标识） -
WHERE user_id = 100 AND status LIKE 'p%'→ key_len 同上，但 status 后续无法走索引排序
如果 key_len 比预期小很多，说明后续索引列根本没参与过滤或排序，联合索引设计可能需要调整。
为什么不能只看 possible_keys 就删索引
possible_keys 是静态候选列表，它不反映真实负载下的索引使用频率。一个索引可能在某个慢查询里是 possible_keys，但在日常高频查询中从不被选中；也可能在低频但关键报表查询中是唯一能避免锁表的索引。
真正判断索引价值，得结合：sys.schema_index_statistics 查命中次数、performance_schema.table_io_waits_summary_by_index_usage 看实际使用率、以及慢日志里哪些查询因缺失该索引而变慢。
直接删掉 possible_keys 里出现但 key 里没出现的索引，常导致某天突然冒出一条 30 秒的报表 SQL——因为那天数据分布变了，优化器重新评估后终于选中了它。
