默认该表为空是因为performance_schema未启用或相关消费者/仪器未开启；需先设performance_schema=on并重启，再执行update performance_schema.setup_consumers和setup_instruments启用索引i/o采集。
performance_schema.table_io_waits_summary_by_index_usage 查不到数据？
默认情况下这个表是空的，不是 MySQL 没记录，而是 performance_schema 本身或相关消费者被禁用了。必须显式启用才能采集索引级 I/O 统计。
先确认 performance_schema 是否开启：
SHOW VARIABLES LIKE 'performance_schema';
如果值为 OFF，需在 my.cnf 中设置 performance_schema=ON 并重启。即使已开启，也得打开具体采集项：
- 执行
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME IN ('events_statements_history_long', 'events_stages_history_long'); - 再启用索引 I/O 相关的 instruments：
UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME LIKE 'wait/io/table/%'; - 生效后，该表才开始累积
COUNT_FETCH、COUNT_INSERT等真实访问次数
查哪个库哪张表的索引用了多少次？
直接查 performance_schema.table_io_waits_summary_by_index_usage，但必须过滤掉系统库，否则结果会被大量内部操作污染：
SELECT OBJECT_SCHEMA AS db, OBJECT_NAME AS table_name, INDEX_NAME, COUNT_FETCH, COUNT_INSERT, COUNT_UPDATE, COUNT_DELETE
FROM performance_schema.table_io_waits_summary_by_index_usage
WHERE OBJECT_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema')
AND OBJECT_SCHEMA = 'your_db_name'
ORDER BY COUNT_FETCH DESC;
COUNT_FETCH 是核心指标：它代表该索引被用于读取（SELECT / WHERE）的次数。值为 0 且持续数天，基本可判定为冗余索引；COUNT_INSERT 高但 COUNT_FETCH 极低，则说明这个索引只拖慢写入，几乎不加速查询。
EXPLAIN 显示用了索引，但 performance_schema 记录为 0？
这是常见错觉，本质是时间尺度不同：EXPLAIN 是单次执行的“理论路径”，而 table_io_waits_summary_by_index_usage 是运行时“真实调用频次”。以下情况会导致两者不一致：
- 查询刚执行完，但 performance_schema 的统计有轻微延迟（通常秒级），刷新一下再查
- 该 SQL 被缓存（Query Cache 或客户端缓存），实际没走引擎层，自然不触发索引 I/O
- 使用了覆盖索引（
Extra: Using index），但 MySQL 8.0 某些版本对覆盖索引的统计归类到“非索引路径”，导致COUNT_FETCH不增 - 查询走了索引，但优化器最终选择回表（
type: ref+key: idx_a+Extra: Using where），此时 I/O 可能被记在聚簇索引上，而非二级索引
sys.schema_unused_indexes 能直接替代手动查表吗？
可以，但要清楚它的局限性。sys.schema_unused_indexes 是基于 table_io_waits_summary_by_index_usage 的封装视图，自动过滤系统库并排除主键/唯一约束索引（避免误删）。但它依赖同一套采集机制——如果 performance_schema 没开全，它也返回空。
更关键的是：它只标出“从未被读取过”的索引（COUNT_FETCH = 0），但不会告诉你这个索引是否在写入时造成明显开销。真正要评估性价比，还得看原始表里的 COUNT_INSERT 和 COUNT_UPDATE 比值。比如一个索引 COUNT_FETCH = 0 但 COUNT_INSERT = 10万+，删它可能让批量导入快 20%，这种细节 sys 视图不体现。
