show index from table_name是最常用、最可靠的查索引命令，返回存储引擎实际维护的实时索引结构，key_name为索引名（primary为主键），column_name与seq_in_index联合标识联合索引列序，支持where过滤字段，无需绕路查元数据表。
直接查 SHOW INDEX 就够了，不用绕路查元数据表——除非你真要批量处理几十个库的索引信息。
show index from table_name 是最常用也最可靠的命令
它返回的是 MySQL 存储引擎（如 InnoDB）实际维护的索引结构，字段含义清晰、实时性强，且兼容所有版本。常见错误是拼错命令（比如写成 show indexes 或漏掉 from），导致语法报错或返回空结果。
-
SHOW INDEX FROM tblname和SHOW KEYS FROM tblname完全等价，后者是前者的别名 - 输出中
Key_name列就是你要的索引名称，PRIMARY表示主键索引，idx_xxx类是普通/唯一索引 - 如果表没建任何索引，结果集为空；但主键会自动创建索引，所以哪怕没显式加索引，
PRIMARY通常也会出现 - 注意：该命令必须指定数据库（用
USE db_name或在表名前加库名，如SHOW INDEX FROM mydb.mytable）
为什么一般不推荐查 information_schema.TABLE_CONSTRAINTS 或 STATISTICS
这些元数据表虽然能查到索引信息，但字段语义模糊、部分字段（如 STATISTICS 中的 SEQ_IN_INDEX）容易理解偏差，且在某些 MySQL 版本中存在缓存延迟——比如刚删完索引，information_schema 里还残留旧记录，而 SHOW INDEX 立刻反映真实状态。
-
information_schema.STATISTICS的INDEX_NAME字段和SHOW INDEX的Key_name对应，但多了冗余字段（如INDEX_COMMENT），反而干扰判断 -
information_schema.TABLE_CONSTRAINTS只包含约束型索引（PRIMARY、UNIQUE、FOREIGN KEY），普通INDEX不会出现 - 跨库批量扫描时才考虑用
SELECT DISTINCT INDEX_NAME FROM information_schema.STATISTICS WHERE TABLE_SCHEMA = 'xxx'，单表诊断没必要
如何快速确认某个字段是否被索引覆盖
光看索引名不够，得知道它由哪些列构成。重点看 SHOW INDEX 输出里的 Column_name 和 Seq_in_index：
- 同一
Key_name下，Seq_in_index = 1的那行是索引的第一列，组合索引顺序不能颠倒 - 如果想查
user_id字段有没有被索引，直接过滤：SHOW INDEX FROM orders WHERE Column_name = 'user_id' -
Sub_part非NULL表示是前缀索引（如VARCHAR(255)只索引前 50 个字符），这种索引对LIKE 'xxx%'有效，但对LIKE '%xxx'无效 - 留意
Null列为YES的索引列——这类索引无法用于IS NOT NULL条件的快速过滤
真正容易被忽略的是 Cardinality 值：它只是估算值，不代表真实区分度。哪怕显示为 0，也不代表索引失效；反过来，数值很高，但如果查询条件匹配度过低（比如 gender 只有 'M'/'F' 两值），优化器仍可能放弃使用该索引。
