mysqlshow 命令不支持 index 子命令，无法显示索引信息；查索引应使用 SHOW INDEX、INFORMATION_SCHEMA.STATISTICS 或 SHOW CREATE TABLE。
mysqlshow 并没有 index 子命令
直接说结论：mysqlshow 命令本身不支持 index 或类似语法，不存在 mysqlshow index 这种用法。它只能列出数据库、表、字段名，但**不输出索引信息**。如果你在文档或脚本里看到类似写法，大概率是混淆了 SHOW INDEX（SQL 语句）和 mysqlshow（客户端工具）。
常见错误现象：
- 执行
mysqlshow --index mydb users报错：未知选项或无输出 - 误以为
mysqlshow mydb users会显示索引，结果只看到字段名和类型 - 在自动化脚本中依赖
mysqlshow提取索引，导致后续逻辑缺失关键信息
真正能查索引的三个可靠方法
查索引必须进 MySQL 客户端执行 SQL，以下三种方式按使用频率排序，各适合不同场景：
1. SHOW INDEX FROM table_name —— 最快上手
- 适用场景：临时确认某张表有哪些索引、列顺序、是否唯一
- 注意
Non_unique = 0表示唯一索引（含主键），= 1是普通索引 - 联合索引靠
Seq_in_index判断顺序，比如idx_a_b_c中a是 1、b是 2、c是 3
2. 查询 INFORMATION_SCHEMA.STATISTICS —— 适合批量/筛选
- 适用场景：写运维脚本、查“哪个字段被哪些索引覆盖”、跨库对比索引重复
- 例如查所有含
email的索引：SELECT INDEX_NAME, TABLE_NAME FROM INFORMATION_SCHEMA.STATISTICS WHERE COLUMN_NAME = 'email' AND TABLE_SCHEMA = 'mydb' - 注意权限：用户需有对
INFORMATION_SCHEMA的SELECT权限
3. SHOW CREATE TABLE table_name —— 看定义是否一致
- 适用场景：核对建表语句与实际索引是否匹配，排查 DDL 执行失败后残留问题
- 输出中找
KEY、UNIQUE KEY、PRIMARY KEY行，注意括号内列顺序和长度（如email(191)） - 不显示索引类型（如 BTREE），但能看出是否为前缀索引
为什么不能靠 DESCRIBE 或 SHOW COLUMNS 查索引？
DESCRIBE users 或 SHOW COLUMNS FROM users 只在 Key 列标出 PRI（主键）、MUL（非唯一索引）、UNI（唯一索引），但无法区分是哪个索引、是否联合、包含哪些列。比如一个字段同时在 idx_email 和 idx_email_status 里，DESCRIBE 只显示 MUL，毫无区分度。
容易踩的坑：
- 把
MUL当成“只有一个索引”，忽略多索引共存的情况 - 看到
Key为空就断定“没索引”，其实可能是联合索引里的非首列（如(a,b)中查b，DESCRIBE不标Key） - 依赖它做索引健康检查，结果漏掉大量隐性问题
验证索引是否真起作用：别只看“有没有”，要看“用没用”
SHOW INDEX 告诉你“有什么”，EXPLAIN 才告诉你“用不用”。执行查询前加 EXPLAIN：
EXPLAIN SELECT * FROM users WHERE email = 'a@b.com';
重点关注：
-
key字段：显示实际使用的索引名，NULL表示未命中 -
key_len：值越小越可能只用了联合索引前缀，比如(a,b,c)上查a=1 AND b=2，key_len对应前两列长度 -
possible_keys：列出所有可用索引，帮你发现“本该用却没用”的索引
联合索引最常被误用：只有满足最左前缀原则才会生效，WHERE b = 2 在 (a,b,c) 上基本等于全表扫描。
真正要动手查索引时，记住一点：绕开 mysqlshow，直奔 SHOW INDEX 或 INFORMATION_SCHEMA；而想确认效果，EXPLAIN 比任何元数据查询都实在。索引名、列序、是否前缀、是否唯一——这些细节一旦错位，优化就从根上偏了。
