低选择性字段（如 status）单独建索引易被优化器跳过，应计算选择性（count(distinct)/count
索引选择性低会导致 WHERE 条件走全表扫描
当字段取值重复率高（比如 status 只有 'active' 和 'inactive' 两种），即使建了索引，优化器大概率会跳过它——因为回表或扫描索引页的成本可能比直接扫聚簇索引还高。
实操建议：
- 用
SELECT COUNT(DISTINCT col) * 1.0 / COUNT(*) FROM table粗略算选择性；结果低于 0.05 就要警惕 - 对低选择性字段，别单独建索引；可考虑和高选择性字段组合成联合索引，把高选择性列放前面
- 如果必须按低选择性字段过滤（如查所有
deleted = 0的记录），配合ORDER BY或LIMIT时，索引可能仍被用上——但得看执行计划，不能假设
EXPLAIN 显示 type=ALL 但表上有索引？先看 key 和 possible_keys
常见错误现象：明明给 user_id 建了索引，EXPLAIN 却显示 type=ALL，key=NULL。这通常不是索引失效，而是优化器认为不用更优。
原因和排查点：
-
possible_keys为空 → 字段类型不匹配（比如查询用字符串'123'查INT列）、隐式转换、或条件用了函数（WHERE YEAR(created_at) = 2024） -
possible_keys有值但key为NULL→ 优化器估算成本后放弃，常见于小表、或索引列在WHERE中未做等值匹配（如仅用于ORDER BY） - 检查
rows估算值是否远大于实际命中的行数——可能是统计信息过期，运行ANALYZE TABLE table_name
联合索引的顺序不是按“常用度”，而是按“过滤强度 + 查询模式”
很多人按 SQL 出现频率排联合索引字段顺序，结果发现 WHERE a = ? AND b = ? 走索引，但 WHERE b = ? 完全不走——这是正常的，不是 bug。
关键逻辑：
- 索引是 B+ 树，数据按最左前缀排序；
(a, b, c)索引能加速a、a,b、a,b,c的等值查询，但对纯b或b,c无效 - 如果高频查
WHERE b = ? AND c > ?，又偶尔查WHERE a = ? AND b = ?，优先建(b, c)，再补单列(a)；别硬凑三列联合索引 - 范围查询（
>,BETWEEN,LIKE 'abc%'）之后的列无法用于索引查找，只能用于过滤；所以(a, b, c)中若b是范围条件，c就不会参与查找
覆盖索引能避免回表，但别为了“覆盖”堆砌冗余字段
当 SELECT 的所有字段都在索引里（比如索引是 (user_id, status, created_at)，查询 SELECT user_id, status FROM t WHERE user_id = 123），MySQL 直接从索引返回结果，不读主键行。
但容易踩的坑：
- 加太多字段进索引会显著增大索引体积，拖慢写入、增加 Buffer Pool 压力；尤其大字段（
TEXT,VARCHAR(2000)）绝对不要进索引 -
SELECT *几乎不可能走覆盖索引；别指望靠一个索引解决所有查询 - 联合索引中字段顺序仍重要：覆盖的前提是查询字段恰好是索引的最左连续前缀子集，不是“包含就行”
复杂点在于，选择性、查询模式、写入负载三者永远在博弈。没有“最优索引”，只有“当前查询 + 当前数据分布 + 当前硬件下代价最小的那个”。上线前一定用真实数据量和慢查询日志验证，别信理论推演。
