如何查询MySQL中哪些表没有使用索引？-mysql教程-PHP中文网

应查询sys.schema_table_statistics表中rows_full_scanned > 100000且table_schema为业务库的记录，执行select table_schema, table_name, rows_full_scanned from sys.schema_table_statistics where rows_full_scanned > 100000 and table_schema not in ('sys','mysql','information_schema') order by rows_full_scanned desc。

如何查询mysql中哪些表没有使用索引？

查哪些表被频繁全表扫描

真正影响性能的不是“没建索引的表”，而是「被反复全表扫描的表」。MySQL 8.0+ 的 sys.schema_table_statistics 表里有现成指标：rows_full_scanned 记录自实例重启以来该表被全表扫描累加的行数。

重点筛选：rows_full_scanned > 100000 且 table_schema 是业务库（排除 'sys'、'mysql'、'information_schema'）。

执行这条 SQL 即可定位热点：

SELECT table_schema, table_name, rows_full_scanned
FROM sys.schema_table_statistics
WHERE rows_full_scanned > 100000
  AND table_schema NOT IN ('sys','mysql','information_schema')
ORDER BY rows_full_scanned DESC;

注意：SELECT COUNT(*) 或 SELECT ... LIMIT 1 也可能触发全表扫描，所以这个值要结合慢查询日志交叉验证，不能单靠它删索引或加索引。

用慢查询日志反向抓未走索引的 SQL

很多表“看起来安静”，但某条高频 SQL 每次都 type: ALL——这才是真瓶颈。关键不是表，是执行计划里的 key: NULL。

必须做两件事：

开启慢查询日志：slow_query_log = ON，设 long_query_time = 1（别用 0，日志会爆炸）
用 mysqldumpslow -s t -t 10 /var/log/mysql/slow.log 找出最耗时的 SQL

对每条慢 SQL 执行：EXPLAIN FORMAT=TREE your_sql，重点看：

MySQL（Linux）

MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。

下载

type 字段是否为 ALL
key 字段是否为 NULL
是否有 <not used></not> 提示

特别警惕：WHERE 条件字段没索引，但 ORDER BY 字段有索引——排序仍可能回表全扫。

别信 INFORMATION_SCHEMA.TABLES 的 INDEX_LENGTH

有人查 INFORMATION_SCHEMA.TABLES 看 INDEX_LENGTH = 0 就断定“缺索引”，这方法错得离谱：

INDEX_LENGTH 包含主键和所有二级索引，但 MyISAM 主键不计入；InnoDB 主键聚簇索引一定存在，所以 INDEX_LENGTH = 0 几乎不会发生
刚 TRUNCATE 的空表，INDEX_LENGTH 也可能为 0，但这跟“缺索引”无关
TABLE_ROWS 是估算值，误差常超 40%，不能作为是否需要索引的依据

想确认某个表有没有有效索引，直接查 SHOW INDEX FROM db.table_name，再结合 EXPLAIN 看实际使用情况。

查哪些索引长期没被用过

有些索引建了但从没被优化器选中，纯属冗余负担。MySQL 5.6+ 提供了运行时统计字段，但要注意：这些字段只在 information_schema.statistics 中部分可用，且 idx_type IS NULL 并非标准字段（多数版本根本不存在）。

更可靠的方式是查 performance_schema.table_io_waits_summary_by_index_usage（需开启 performance_schema）：

SELECT OBJECT_SCHEMA, OBJECT_NAME, INDEX_NAME, COUNT_STAR
FROM performance_schema.table_io_waits_summary_by_index_usage
WHERE INDEX_NAME IS NOT NULL
  AND COUNT_STAR = 0
  AND OBJECT_SCHEMA NOT IN ('sys','mysql','information_schema');

注意：COUNT_STAR = 0 表示自监控开启后该索引从未被用于查找（不含插入/更新维护开销）。但该视图默认不记录历史，重启后归零——所以必须持续开启并定期快照，否则容易误删正在被应用层缓存绕过的“冷索引”。

真正难判断的，不是“有没有索引”，而是“这个索引到底有没有被当前业务流量路径触达”。一次 EXPLAIN 不代表永远，一个 COUNT_STAR = 0 也不代表永远不用——得看它是否出现在慢查询里、是否被高频事务覆盖、是否被 ORM 自动生成的 WHERE 条件命中。