MySQL查看表索引最直接方式是查询information_schema.STATISTICS表，可获取索引名、列名、顺序、唯一性等完整信息，但不包含FULLTEXT和SPATIAL索引细节；也可用SHOW INDEX FROM table_name快速查看单表索引。

查所有索引用 information_schema.STATISTICS 表最直接

MySQL 不提供类似 PostgreSQL 的 \d+ table 命令，但 information_schema.STATISTICS 是官方标准方式，能拿到索引名、列、顺序、是否唯一等完整信息。注意它不包含全文索引（FULLTEXT）和空间索引（SPATIAL）的细节，这类索引需额外查 information_schema.INNODB_FT_DEFAULT_STOPWORD 或表结构本身。

常用查询写法：

SELECT 
  TABLE_NAME,
  INDEX_NAME,
  COLUMN_NAME,
  SEQ_IN_INDEX,
  INDEX_TYPE,
  NON_UNIQUE
FROM information_schema.STATISTICS
WHERE TABLE_SCHEMA = 'your_db_name'
ORDER BY TABLE_NAME, INDEX_NAME, SEQ_IN_INDEX;

• SEQ_IN_INDEX 是关键：值为 1 表示该列是索引的第一列，联合索引靠它判断顺序
• NON_UNIQUE = 0 表示唯一索引（含主键），= 1 是普通索引
• 主键索引的 INDEX_NAME 固定为 PRIMARY，别误以为是用户创建的

用 SHOW INDEX FROM table_name 更快，但只限单表

这是命令行或脚本中快速检查某张表索引的首选，比查 information_schema 开销小，且返回字段更直观（比如 Key_name、Seq_in_index、Collation）。

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

执行示例：

SHOW INDEX FROM users;

• 结果中 Cardinality 是估算值，不一定实时准确，不能用于判断索引是否“有效”
• Collation 为 A 表示升序，NULL 表示未排序（如哈希索引，但 MySQL 当前引擎基本不用）
• 如果某列 Sub_part 有数值（如 100），说明是前缀索引，只索引该列前 N 个字符

为什么 information_schema.TABLES 和 COLUMNS 查不到索引？

新手常误以为索引信息存在 TABLES（只存表元数据如引擎、行数）或 COLUMNS（只存字段定义），其实它们压根不记录索引结构。真正承载索引定义的是 STATISTICS 和 KEY_COLUMN_USAGE —— 后者只存外键关联的列级约束，对普通索引没用。

• KEY_COLUMN_USAGE 只反映外键约束，不是索引本身；即使你建了外键索引，它也不体现索引名或类型
• STATISTICS 中同一索引可能有多行（联合索引每列一行），要按 INDEX_NAME + TABLE_NAME 分组才能看清结构
• MyISAM 表的索引信息也在 STATISTICS，但 INDEX_TYPE 值固定为 BTREE，无实际区分意义

InnoDB 表的隐藏主键会影响 STATISTICS 查询结果吗？

不会。只有当你没定义主键且没唯一非空索引时，InnoDB 才会生成隐藏的 row_id，但它不暴露在 information_schema.STATISTICS 中——既没有 INDEX_NAME，也不会出现在 SHOW INDEX 结果里。所以你查不到它，也不用担心它干扰你的索引分析。

• 如果你看到某张 InnoDB 表没有 PRIMARY 索引，但 STATISTICS 里又确实没任何索引记录，大概率就是用了隐藏 row_id
• 这种表无法被高效范围扫描，线上应避免；检查方式是 SHOW CREATE TABLE t 看是否有 PRIMARY KEY
• STATISTICS 中的 INDEX_NAME 为空字符串的情况极少，通常意味着数据字典损坏，不是正常行为

查索引这事，重点不在“能不能查到”，而在于理解每条记录对应的是联合索引里的哪一列、是否前缀、是否唯一——这些细节直接决定查询能否走索引。别光盯着有没有索引，得看它长什么样。