先关闭 innodb_dedicated_server 再手动配置：MySQL 8.0 默认开启该参数，会强制按物理内存75%自动设 innodb_buffer_pool_size，无视其他进程和系统余量；必须在 my.cnf 中显式设为 OFF 并重启生效，动态设置无效。
先关掉 innodb_dedicated_server 再动手
MySQL 8.0 默认开启 innodb_dedicated_server=ON，它会直接忽略你写的 innodb_buffer_pool_size，按物理内存的 75% 自动设值。这不是“智能”，而是“霸道”——它不看系统里有没有 Redis、Nginx、Java 进程，也不管 OS 是否只剩 512MB 可用内存，硬塞满就完事。
查当前状态：SHOW VARIABLES LIKE 'innodb_dedicated_server';，如果返回 ON，立刻在 /etc/my.cnf 的 [mysqld] 段加一行：innodb_dedicated_server = OFF。改完必须重启 MySQL，SET GLOBAL 动态设置完全无效。
算值要同时满足三个硬约束
不能直接填 64G 或 70%，否则大概率被自动对齐或触发 OOM。必须同步盯住：
-
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 容易误判，它反映的是最近几秒热度，而真实瓶颈藏在长期空闲页堆积或突发读放大里。
MySQL8 CRM Schema Design Expert
下载
面向 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 = 'Innodb_buffer_pool_pages_free' OR variable_name = 'Innodb_buffer_pool_pages_total';
动态调整时最容易踩的坑
MySQL 5.7+ 支持在线调大 innodb_buffer_pool_size，但以下情况会失败或埋雷：
- 新值不是 chunk 对齐的倍数 → MySQL 自动向下取整到最近合法值，你根本没设成功
- 没同步调
innodb_buffer_pool_instances→ 实例数太少，高并发下内部锁竞争反而升高（SHOW ENGINE INNODB STATUS里看 “Mutex spin waits” 异常高） - 调大后没观察
vmstat 1的si/so（swap in/out）→ 出现非零值就是系统开始 swap，性能已断崖下跌
真正难的不是算出一个数字，而是让这个数字在 OS 内存、热数据分布、InnoDB 内部 chunk 对齐、以及并发线程调度之间，严丝合缝地咬合上。漏掉任意一环，配置就只是纸面正确。
