SHOW INDEX结果中Key_name为索引名（PRIMARY为主键），Seq_in_index表示联合索引字段顺序，Collation为A表升序、NULL表不排序，Cardinality是采样估算的去重值数量，需ANALYZE TABLE刷新。
SHOW INDEX 返回字段都代表什么
执行 SHOW INDEX FROM table_name 后，结果里十几列看着眼花，但真正常看的就几个：Key_name 是索引名（PRIMARY 表主键，NULL 表非唯一索引），Seq_in_index 表示字段在联合索引里的顺序，Collation 为 A 表升序、NULL 表不排序（如全文索引），Cardinality 是 MySQL 估算的去重值数量——它不实时更新，ANALYZE TABLE 后才刷新，别拿它当精确统计。
容易踩的坑：
-
Cardinality值为NULL或极小（比如 1），不代表没索引，可能是表刚建、没 ANALYZE 过，或字段几乎全重复 -
Sub_part非空说明是前缀索引（比如VARCHAR(255)只索引前 50 字符），查WHERE col = 'xxx'仍能走索引，但ORDER BY col可能失效 -
Index_type显示FULLTEXT或SPATIAL时，普通=查询不走索引，得用MATCH ... AGAINST
怎么快速定位“没用上”的索引
不是所有出现在 SHOW INDEX 结果里的索引都在干活。先看 cardinality / table_rows 比值：低于 0.001 通常意味着区分度太差，优化器大概率跳过；再结合慢查询日志里的 key 字段确认实际是否命中。
实操建议：
- 用
EXPLAIN SELECT ...对比加索引前后key和rows变化，比光看SHOW INDEX有用得多 -
Key_name为PRIMARY但Rows扫描量极大，说明 WHERE 条件没利用主键范围（比如用了函数：WHERE YEAR(created_at) = 2023） - 联合索引
(a,b,c)，若只查WHERE b = ?，该索引完全无效——Seq_in_index = 1的字段必须出现在条件中（最左前缀原则）
SHOW INDEX 和 INFORMATION_SCHEMA.STATISTICS 有啥区别
两者数据来源一致，但 SHOW INDEX 更轻量、权限要求低（只需 SELECT），而查 INFORMATION_SCHEMA.STATISTICS 需要 SELECT 权限且可能被 SQL_SAFE_UPDATES 拦截。另外，后者字段名更直白（如 INDEX_NAME 而非 Key_name），但多了冗余列，还可能因元数据锁导致卡顿。
选哪个？
- 日常排查，无脑用
SHOW INDEX FROM tbl，快、稳、字段够用 - 需要跨库批量分析索引（比如写脚本导出所有表的
Cardinality），用INFORMATION_SCHEMA.STATISTICS更方便拼 WHERE - 如果连
SHOW INDEX都返回空，先确认用户是否有该表的 SELECT 权限——没权限时它静默返回空结果，不报错
Cardinality 为什么不准，以及怎么让它准一点
Cardinality 是采样估算值，默认每 8 个页抽 1 行，表越大误差越明显。InnoDB 不在每次 DML 后更新它，所以大批量 INSERT/DELETE 后，它可能还停留在旧状态。
让它靠谱点的办法：
- 手动执行
ANALYZE TABLE table_name，强制重新采样（注意：会加表级读锁，大表慎用） - 调高采样精度：设
innodb_stats_persistent_sample_pages = 128（默认 20），配合innodb_stats_persistent = ON让统计更稳定 - 避免在从库上依赖
Cardinality做判断——从库延迟可能导致采样基于过期数据
最麻烦的其实是：即使 Cardinality 准了，优化器也可能因为成本模型偏差选错索引。这时候得靠 FORCE INDEX 或调整 optimizer_switch，而不是继续盯着 SHOW INDEX 看。
