命中率低需先计算Hit Rate = 1 - (Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests)，低于95%才表明物理读过多；若>99%，盲目调大innodb_buffer_pool_size无效且可能引发swap。
直接看命中率公式，别只盯着 innodb_buffer_pool_size 调大小
命中率低，不等于必须盲目调大 innodb_buffer_pool_size。真正该先算的是：Hit Rate = 1 - (Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests)。这个比值低于 95%，才说明物理读太多、缓存没兜住；如果 >99%，再调大基本无效，甚至可能挤占 OS 内存引发 swap。
常见错误现象：QPS 上不去、慢查询突增、SHOW ENGINE INNODB STATUS 里 BUFFER POOL AND MEMORY 显示 Free buffers 长期为 0，但 Pages made young 极低——这说明 LRU 没激活，不是内存不够，而是访问模式冷热混杂或存在全表扫描。
- 用
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%'获取实时分子分母 - 避免用
SHOW STATUS（会重置计数器），必须用GLOBAL级别 - 计算周期建议取 5–10 分钟，避开瞬时抖动
动态调整 innodb_buffer_pool_size 的三个硬约束
MySQL 5.7.5+ 支持在线调整，但不是“设多少就生效多少”。它按 innodb_buffer_pool_chunk_size 的整数倍增减，默认是 128MB（可查 SELECT @@innodb_buffer_pool_chunk_size）。如果你当前是 8GB，想调到 10GB，而 chunk 是 128MB，实际只能调到 10240MB（80 × 128MB）或 10112MB（79 × 128MB），不能精确到字节。
容易踩的坑：
-
SET GLOBAL innodb_buffer_pool_size = 10737418240可能被自动向下取整，需用SELECT @@innodb_buffer_pool_size确认最终值 - 调整过程会触发 buffer pool 重建，期间并发写入可能短暂阻塞（尤其大实例），别在高峰做
- 若
innodb_buffer_pool_instances设置不合理（如 32GB 缓冲池却只设 1），会导致内部 mutex 争用，反而降低吞吐
配合 innodb_buffer_pool_instances 拆分才能释放多核性能
单个缓冲池在高并发下会成为锁瓶颈。MySQL 8.0+ 虽默认优化了内部结构，但 innodb_buffer_pool_instances 仍需手动配——原则是：每个 instance 至少 1GB，上限建议 ≤ CPU 核心数。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
例如总内存 64GB，设 innodb_buffer_pool_size = 45G，那么 innodb_buffer_pool_instances = 8 更合理（45/8 ≈ 5.6GB/instance）；设成 16 就浪费调度开销，设成 4 则单 instance 过大易争抢。
注意：
- 该参数**不可动态修改**，必须改配置文件 + 重启生效
- MySQL 8.0.22+ 引入了自适应实例管理，但仅限于极少数云托管版本，通用部署仍需手动配
- 检查是否生效：执行
SHOW VARIABLES LIKE 'innodb_buffer_pool_instances'，再看SHOW ENGINE INNODB STATUS\G中各 instance 的pages分布是否均衡
命中率上不去？先关掉干扰项再诊断
很多情况下命中率低，根本不是缓冲池小，而是其他机制在“抢”内存或制造无效读：
- 大范围
SELECT *或未走索引的WHERE查询，会把大量冷数据页拖进 buffer pool，快速挤掉热点页 -
innodb_old_blocks_pct默认 37，但若业务以短时批量导入为主，可临时调高（如 75），防止新读入页过早进入 young 区干扰 LRU - MySQL 8.0+ 已移除 query cache，但若从旧版本升级，确认没残留
query_cache_type=1配置——它和 buffer pool 争内存且早已废弃 - 频繁创建隐式临时表（
created_tmp_disk_tables > 0）也会吃掉 buffer pool 外的内存，间接加剧压力
最常被忽略的一点：buffer pool 命中率只是结果，不是根因。真正要盯的是“哪些 SQL 在反复触发物理读”，用 performance_schema.events_statements_summary_by_digest 找出 rows_examined 高但 rows_sent 低的语句，它们才是命中率的真正杀手。
