跳转到主内容
websoft网络软件专家 - 深耕网络技术,打造实用软件!

SQL如何查看哪些索引从未被使用_sys.schema_unused_indexes视图

MySQL 8.0.1+才支持sys.schema_unused_indexes视图,依赖performance_schema.table_io_waits_summary_by_index_usage统计,5.7及更早版本不存在该视图;其结果仅为“近期未用”,需人工核验业务逻辑与外键依赖,不可直接执行drop_statement。 MySQL 8.0+ 才有
sys.schema_unused_indexes
,低版本直接查不了 这个视图是
sys
库里的一个只读视图,底层依赖
performance_schema
的索引统计(
table_io_waits_summary_by_index_usage
),而该表从 MySQL 8.0.1 开始才支持记录「索引未被使用」的场景。MySQL 5.7 及更早版本压根没有这个视图,执行
SELECT * FROM sys.schema_unused_indexes;
会报错
Table 'sys.schema_unused_indexes' doesn't exist
。 如果你在 5.7 或 MariaDB 上看到有人提这个视图,基本是记混了或者环境实际是 8.0+。 确认版本:
SELECT VERSION();
确认
performance_schema
已启用且相关消费者已打开:
SELECT * FROM performance_schema.setup_consumers WHERE NAME LIKE '%statements%' OR NAME LIKE '%waits%';
,其中
events_waits_summary_by_index_usage
必须为
ENABLED
视图本身不实时刷新——它只反映自上次
FLUSH TABLES
或服务器重启后、
performance_schema
收集到的统计周期内的状态
sys.schema_unused_indexes
返回的是“近期未用”,不是“永远没用” 它列出的索引只是在当前
performance_schema
统计窗口内(通常是自启动或上次清空以来)没有被任何语句通过索引查找(
index_lookup
)访问过。但以下情况会导致误判: 索引只用于排序或覆盖扫描(
Using index
),但没触发
index_lookup
——这类使用不会被计入「已使用」,可能被误标为 unused 查询走的是联合索引的最左前缀,但视图把整个联合索引都列为 unused(因为非前缀字段没单独被查过) 应用刚上线、流量还没打进来,或 DBA 刚启用了
performance_schema
,统计期太短 某些 DDL 操作(如
ANALYZE TABLE
)会触发隐式索引访问,但不走常规查询路径,也不会被统计 所以它更适合做「初筛」,而不是直接删索引的依据。 查出来的结果里
schema_name
和
index_name
要人工核对业务逻辑 视图返回的字段包括
object_schema
、
object_name
、
index_name
、
type
(PRIMARY/UNIQUE/BASE)、
drop_statement
(建议删除语句)。但别急着复制
drop_statement
就跑:
drop_statement
不检查外键依赖——如果该索引被外键引用,直接执行会报错
Cannot drop index 'xxx': needed in a foreign key constraint
有些索引虽未被 SELECT 使用,但被
INSERT ... ON DUPLICATE KEY UPDATE
或
REPLACE INTO
依赖来判断冲突,删了会出错 全文索引(
FULLTEXT
)和空间索引(
SPATIAL
)在视图中可能显示为 unused,但它们的使用模式不走普通 wait 统计,不能信 务必结合
SHOW CREATE TABLE `table_name`;
看索引定义,再翻代码或慢日志确认有没有隐式使用场景 替代方案:手动查
performance_schema
原表更可控 如果想绕过
sys
视图的封装、看原始统计,可以直接查底层表:
SELECT OBJECT_SCHEMA, OBJECT_NAME, INDEX_NAME FROM performance_schema.table_io_waits_summary_by_index_usage WHERE COUNT_READ = 0 AND INDEX_NAME IS NOT NULL AND OBJECT_SCHEMA NOT IN ('mysql', 'sys', 'information_schema', 'performance_schema');
注意点:
COUNT_READ = 0
表示没发生过索引查找,比视图更原始;但它不区分「真没用」和「统计被重置过」 必须排除系统库,否则会看到一堆
innodb
内部索引(比如
INNODB_SYS_TABLES
的主键) 这个表的数据是累积的,但重启 MySQL 后会清零——所以线上长期运行的实例,结果更有参考性;刚重启不久的实例,几乎全是 0 如果你开了
userstat
(已废弃)或用了旧版监控工具,可能干扰判断,优先以
table_io_waits_summary_by_index_usage
为准 真正要动手删索引前,得在低峰期先
SET SESSION optimizer_switch='use_index_extensions=off';
测试下关键 SQL 执行计划有没有崩,再决定动不动手。

相关文章