必须先关闭innodb_dedicated_server=ON，否则手动配置的innodb_buffer_pool_size会被自动覆盖；关闭后需重启MySQL，并确保设置值满足OS余量、热数据量及chunk对齐三重约束。
先关掉 innodb_dedicated_server 再动手
MySQL 8.0 默认开启 innodb_dedicated_server=ON，它会无视你写的 innodb_buffer_pool_size，直接按物理内存的 75% 自动设值。但这个策略只适用于“服务器上只有 MySQL”这种理想场景——现实中混部 Nginx、Redis、Java 应用太常见，它却不管其他进程，常把 buffer pool 设得过大，挤占 OS 内存，触发 swap 或 OOM。
查当前状态：SHOW VARIABLES LIKE 'innodb_dedicated_server';，如果返回 ON，立刻在 my.cnf 的 [mysqld] 段加一行：innodb_dedicated_server = OFF。改完必须重启 MySQL，SET GLOBAL 动态设置不生效。
算出合理值要盯住三个硬约束
不能直接填 “64G” 或 “70%”，必须同时满足：
- OS 和其他服务余量：至少留 2GB 给操作系统；混合部署（如跑着 Redis + PHP-FPM）需先用
free -m看实际可用内存，再扣掉其他常驻进程内存，剩余的 60%~70% 才是安全上限 - 热数据估算锚点：运行
SELECT SUM(data_length + index_length) FROM information_schema.tables WHERE engine='InnoDB' AND table_schema NOT IN ('mysql','information_schema','performance_schema');，再结合业务判断哪些表是高频访问的（比如最近 90 天订单），这才是 buffer pool 的理论上限 - chunk 对齐规则：值必须是
innodb_buffer_pool_chunk_size × innodb_buffer_pool_instances的整数倍。默认 chunk 是 128MB、instances 是 1，所以最小合法步进是 128MB；若设了innodb_buffer_pool_instances = 8，那最小步进就是 1024MB（8 × 128MB），填 49G 会被自动向下对齐到 48G
验证配置是否真起作用，别只看命中率
命中率高 ≠ 配置合理。单看 Innodb_buffer_pool_hit_rate 容易误判，它反映的是最近几秒热度，而真实瓶颈藏在长期空闲页堆积或突发读放大里。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
必须结合两个指标看：
- 命中率持续低于 99.0%？执行：
SELECT (1 - (Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests)) * 100 AS hit_rate FROM performance_schema.global_status WHERE variable_name IN ('Innodb_buffer_pool_reads', 'Innodb_buffer_pool_read_requests'); - 空闲页占比长期 >25%？说明设大了：
SELECT (Innodb_buffer_pool_pages_free / Innodb_buffer_pool_pages_total) * 100 AS free_pct FROM performance_schema.global_status WHERE variable_name IN ('Innodb_buffer_pool_pages_free', 'Innodb_buffer_pool_pages_total'); - 更关键的信号：
Innodb_buffer_pool_wait_free持续非零，或Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests > 0.01（即磁盘读占比超 1%），基本可判定偏小
在线调大后反而变慢？那是 chunk 预热没跟上
MySQL 8.0 支持在线调整 innodb_buffer_pool_size，但调整不是瞬间完成的——它是以 chunk 为单位逐步加载的，默认每秒最多加载一个 chunk（由 innodb_buffer_pool_chunk_size 决定）。如果你从 32G 调到 64G，而 chunk 是 128MB，那就要加载 256 个 chunk，可能耗时数分钟。
这期间会出现明显延迟，因为新数据还没加载进来，旧缓存又在被逐步替换，命中率骤降。此时观察 SHOW ENGINE INNODB STATUS\G 中 “BUFFER POOL AND MEMORY” 部分的 “Pages loaded” 和 “Pages flushed” 增速，就能确认是否还在预热中。
真正容易被忽略的是：调大之后，innodb_buffer_pool_instances 如果没同步调整，会导致每个实例过小（比如总池 64G、instances=1，单实例就 64G），失去并发控制意义；建议按 CPU 核心数设（不超过 8），且确保每个实例 ≥1GB。
