SHOW INDEX 只显示索引结构定义，如名称、列序、前缀长度、基数等，但无法反映索引是否被实际使用、使用频率或单条查询是否命中；判断索引是否生效必须依赖 EXPLAIN、Handlerread* 状态变量、慢日志及 performance_schema。
SHOW INDEX 能看到什么，不能看到什么
SHOW INDEX FROM tblname 只展示索引的结构定义，不反映运行时是否被用、用了多少次。它输出的 Cardinality 是唯一值估算，Seq_in_index 表示联合索引中列的顺序，Sub_part 告诉你是否只索引了前 N 个字符——这些对建索引有用，但和“这次查询有没有走索引”毫无关系。
常见误判是：看到 Key_name 非空，就以为索引生效了。其实它只是告诉你“这张表有这个索引”，不是“这条 SQL 用了它”。真正判断是否命中，得看执行时的行为，不是看定义。
EXPLAIN 是查单条 SQL 是否走索引的唯一可靠手段
对具体语句执行 EXPLAIN SELECT ...，重点盯三个字段：
-
type：必须是const、eq_ref、ref、range才算有效走索引；ALL就是全表扫描，哪怕key列显示了索引名，也等于没用 -
key：实际选用的索引名，为NULL说明彻底没走索引 -
rows：优化器预估扫描行数，如果接近表总行数，基本可以判定索引失效
注意：rows 是估算值，统计信息过期（比如刚大批量导入数据后没跑 ANALYZE TABLE）会导致它严重失真。别光信这个数字，配合 Handler_read_rnd_next 看真实扫描行为更准。
全局索引命中率只能靠 Handler_read_* 状态变量估算
执行 SHOW STATUS LIKE 'Handler_read%'，重点关注：
-
Handler_read_key：通过索引定位到某一行的次数 -
Handler_read_rnd_next：全表扫描时逐行读取的次数（越高越危险）
索引命中率粗略公式是：(Handler_read_key) / (Handler_read_key + Handler_read_rnd_next) * 100%。90% 是警戒线，低于这个值说明大量查询在做全表扫描。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
但要注意：这个比率是全局累计值，掩盖了单条慢查询的问题。比如 99% 的请求都很快，1% 的慢查询拖垮整体，你从这个比率里根本看不出哪条 SQL 在作怪。
真正要定位低效查询，得结合慢日志和 performance_schema
仅靠 SHOW INDEX 和状态变量，你永远不知道哪条 SQL 在浪费资源。必须做两件事：
- 开慢查询日志：
SET GLOBAL slow_query_log = ON，并设long_query_time = 1；把log_output设成'TABLE'，后续查mysql.slow_log表更方便 - 对慢日志里的语句逐条
EXPLAIN，特别留意Extra字段含Using filesort或Using temporary的——这类语句即使走了索引，也可能因排序/分组触发额外 I/O
MySQL 5.6+ 还可查 performance_schema.table_io_waits_summary_by_index_usage，它记录各索引被实际调用的次数，比 SHOW INDEX 更贴近真实使用情况，但只统计打开该功能之后的访问。
最常被忽略的一点：索引存在 ≠ 查询会用。是否命中取决于 WHERE 条件写法、数据类型是否匹配、联合索引列顺序是否满足最左前缀——这些细节，SHOW INDEX 一个字都不会告诉你。
