真实命中率需用Innodb_buffer_pool_read_requests与Innodb_buffer_pool_reads计算：(requests−reads)/requests×100%，因SHOW ENGINE INNODB STATUS中的Buffer pool hit rate仅统计约1000次逻辑读的滑动窗口，瞬时抖动大、不可累加、不能告警。
直接查 Innodb_buffer_pool_read_requests 和 Innodb_buffer_pool_reads 才准
别信 SHOW ENGINE INNODB STATUS\G 里那个 Buffer pool hit rate ——它只统计最近约 1000 次逻辑读的滑动窗口，瞬时抖动大、不可累加、不能告警。真实命中率必须用两个全局状态变量算：Innodb_buffer_pool_read_requests（总逻辑读请求数）减去 Innodb_buffer_pool_reads（实际磁盘页读次数），再除以前者。
执行这组命令一次性获取快照，避免时间错位：
mysql> SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%';
然后手动代入：(requests − reads) / requests × 100%。或者用这个安全单查：
SELECT ROUND((1 - reads / requests) * 100, 2) AS hit_rate, reads, requests FROM (SELECT VARIABLE_VALUE + 0 AS reads FROM performance_schema.global_status WHERE VARIABLE_NAME = 'Innodb_buffer_pool_reads') r CROSS JOIN (SELECT VARIABLE_VALUE + 0 AS requests FROM performance_schema.global_status WHERE VARIABLE_NAME = 'Innodb_buffer_pool_read_requests') req;
- 采样间隔建议 5–10 分钟，避开瞬时扫描干扰
- 必须用
SHOW GLOBAL STATUS，SHOW STATUS会重置计数器 - 刚调过
innodb_buffer_pool_size后要等至少 5 分钟再采，等Innodb_buffer_pool_pages_total稳定
命中率低于 95% 不等于马上加内存
先看 Innodb_buffer_pool_reads 的绝对值和变化趋势。如果命中率 92%，但 Innodb_buffer_pool_reads 每秒才 2～3 次，说明负载本来就很轻；反过来，99.3% 却每秒稳定 120+ 次物理读，IO 压力根本没下来。
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 持续
- 95%–98%：结合
iotop -p $(pgrep mysqld)看实际 IOPS，确认是不是脏页刷写或预读导致 - ≥ 99.5% 但
Innodb_buffer_pool_reads每秒仍 > 50：大概率是 SQL 本身问题，比如ORDER BY触发 filesort 或没走索引的范围查询
调整 innodb_old_blocks_pct 和 innodb_old_blocks_time 比盲目扩 buffer pool 更有效
当存在报表查询、大范围 SELECT * 或周期性分析任务时，冷数据大量涌入 Buffer Pool，把热数据挤出 Young 区，导致命中率掉到 700～800（单位是千分比），但 Free buffers 为 0、Pages read ahead 却很高——这时调大 innodb_buffer_pool_size 只是白费内存。
-
innodb_old_blocks_pct默认 37，OLTP 场景可不动；混合负载建议设为 25～30；BI 直连场景可压到 15～20（同步调高innodb_old_blocks_time） -
innodb_old_blocks_time默认 1000ms，但很多分析 SQL 执行超 2 秒，建议按慢查询 P95 时长 + 500ms 设（如 P95 是 2300ms，则设 2800） - 这两个参数都支持
SET GLOBAL动态生效，无需重启 - 绝对不要设
innodb_old_blocks_pct = 5或= 95—— 前者让预读失效严重，后者等于放弃 LRU 分代保护
调 innodb_buffer_pool_size 要注意 chunk 对齐和实例拆分
MySQL 不是“你设多少就给多少”，它按 innodb_buffer_pool_chunk_size 的整数倍分配，默认 128MB。比如当前 8GB，想调到 10GB，而 chunk 是 128MB，那实际只能到 10112MB（79 × 128MB）或 10240MB（80 × 128MB）。
- 调完必须查
SELECT @@innodb_buffer_pool_size确认最终值，别只信 SET 命令 -
innodb_buffer_pool_instances不可动态改，必须配置文件 + 重启；原则是每个 instance ≥ 1GB，且 ≤ CPU 核心数；例如 45GB 总池，设 8 个 instance 比设 1 或 16 更合理 - 调大过程会触发 buffer pool 异步重建，期间可能短暂阻塞写入，别在业务高峰做
真正卡住命中的，往往不是内存大小，而是访问模式和参数协同。盯住 Innodb_buffer_pool_reads 的绝对值、Pages read ahead 和慢查询执行计划，比反复猜 innodb_buffer_pool_size 有用得多。
