MySQL INNODB_CACHED_INDEXES 查看每个索引的缓存页

排查 InnoDB 索引是否经常进入缓冲池时，不必先翻性能日志。MySQL 的 INFORMATION_SCHEMA.INNODB_CACHED_INDEXES 会按索引给出已经缓存的索引页数量，先用它定位对象，再决定是否继续看访问次数和缓冲池压力。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/information-schema-innodb-cached-indexes-table.html

先看懂三个字段，再判断结果

这张表的核心字段很少：SPACE_ID 表示表空间，INDEX_ID 是实例内索引标识，N_CACHED_PAGES 是该索引已经缓存到 buffer pool 的页数。官方文档明确说明，后一个数字从服务启动后开始累计，因此刚重启的实例不能和运行了很久的实例直接比较。

先从原始表确认数据是否存在：

SELECT SPACE_ID, INDEX_ID, N_CACHED_PAGES
FROM INFORMATION_SCHEMA.INNODB_CACHED_INDEXES
ORDER BY N_CACHED_PAGES DESC;
-- 先看原始缓存页记录，按页数降序找出需要进一步映射的索引

把 INDEX_ID 还原成表名和索引名

只看 INDEX_ID=65 很难采取动作。MySQL 官方示例使用 INNODB_INDEXES 和 INNODB_TABLES 补齐索引与表的名称，实际排查也建议一次把页数带出来：

SELECT
  tables.NAME AS table_name,
  indexes.NAME AS index_name,
  cached.SPACE_ID,
  cached.INDEX_ID,
  cached.N_CACHED_PAGES
FROM INFORMATION_SCHEMA.INNODB_CACHED_INDEXES AS cached
JOIN INFORMATION_SCHEMA.INNODB_INDEXES AS indexes
  ON indexes.INDEX_ID = cached.INDEX_ID
JOIN INFORMATION_SCHEMA.INNODB_TABLES AS tables
  ON tables.TABLE_ID = indexes.TABLE_ID
ORDER BY cached.N_CACHED_PAGES DESC;
-- 通过索引 ID 和表 ID 映射可读名称，再按缓存页数排序定位对象

若只关心某张表，可以再加 WHERE tables.NAME = 'app/orders'。这里的名称通常包含库名和表名，生产环境不要把字符串过滤写成未经确认的模糊条件，否则容易把同名表混在一起。

数字变大时，按清单继续排查

N_CACHED_PAGES 较大只说明该索引有较多页面被记录为缓存过，不能单独证明它造成了内存压力，也不能替代查询命中率。建议按下面顺序判断：

1. 先记下实例启动时间和采样时刻，避免把刚重启的低值误判为冷索引。
2. 用表名和索引名对照慢查询、访问频率与执行计划，确认它是否真的服务于当前负载。
3. 再结合 buffer pool 总体指标和索引实际大小判断是否存在内存竞争。
4. 只有证据指向索引设计问题时，才进入覆盖索引、冗余索引或重建方案评估。

查询报权限错误时，先确认当前账号拥有 PROCESS 权限；权限补齐后仍应使用只读查询。不要为了让数字“好看”而清空或重启服务，因为重启会让这类从启动后累积的观察重新开始。

相关问题

这个表能直接算索引命中率吗？

不能。它给出缓存页数量，不提供请求总数、命中次数和未命中次数，命中率需要结合其他运行指标与时间窗口判断。

为什么 INDEX_ID 查不到表名？

先确认联结条件使用了 indexes.INDEX_ID = cached.INDEX_ID，并且继续通过 indexes.TABLE_ID = tables.TABLE_ID 映射；同时检查实例版本和权限。

服务重启后数字为什么变小？

这是统计边界变化的正常现象。该数值会从最近一次 MySQL Server 启动后重新累计，应在相近运行时长和相似负载下比较。