必须优先保障innodb_buffer_pool_size，因其直接影响innodb缓冲池命中率和磁盘io压力；myisam已非主流，key_buffer_size应“能小则小”；会话级参数需按max_connections动态计算，避免oom。
不能简单按比例分配，必须优先保障 innodb_buffer_pool_size，再为 key_buffer_size 留出有限空间，且两者之和不能挤占系统基础内存。
为什么 innodb_buffer_pool_size 必须优先保底
InnoDB 是 MySQL 5.7+ 默认引擎，几乎所有业务表都走它；MyISAM 多用于历史日志表或只读归档表。缓冲池命中率直接决定磁盘 IO 压力，innodb_buffer_pool_size 小了，哪怕 key_buffer_size 调得再高，整体性能也上不去。
常见错误现象：SHOW ENGINE INNODB STATUS 中 “Buffer pool hit rate” 长期低于 99%，同时 Threads_connected 不高但查询响应变慢——大概率是缓冲池被人为压低了。
- 物理内存 ≤ 16GB：先划出 60%~70% 给
innodb_buffer_pool_size（例如 12GB 内存 → 至少 7G） - 物理内存 > 16GB：按 70%~80% 划，但务必预留 ≥2GB 给 OS 和其他进程（如 Redis、Nginx）
- 若 MySQL 与 Redis 共机，
innodb_buffer_pool_size建议上限设为总内存 × 0.65，否则可能触发 OOM 导致 Redis 连接失败
key_buffer_size 只能“见缝插针”，且上限很明确
key_buffer_size 仅对 MyISAM 索引生效，数据页完全依赖 OS 缓存。它不共享、不复用，每个连接不会额外申请，但一旦设大，就永久占用——所以不是“够用就行”，而是“能小则小”。
使用场景：你确认有 MyISAM 表（SELECT ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'db_name'），且该表索引频繁读取（如日志汇总视图）。
- 若 MyISAM 表总量 key_buffer_size = 64M 足够
- 若 MyISAM 索引文件（
.MYI）总和约 2~3GB，可设为256M～512M，但不得超过innodb_buffer_pool_size的 1/10 - 绝对避免设置
key_buffer_size > 1G：实测在混合引擎下，超过此值后 OS 缓存压力陡增，MyISAM 数据读反而变慢
会话级参数必须按 max_connections 动态算，不能照搬默认值
像 sort_buffer_size、read_buffer_size 这类参数，是每个连接独占的。InnoDB 和 MyISAM 都会用到它们——尤其是 ORDER BY 或全表扫描时。如果 max_connections = 500，而 sort_buffer_size = 2M，光这一项就吃掉 1GB 内存。
容易踩的坑：把测试环境（max_connections = 100）的配置直接上生产，结果并发一上来，Out of memory: Kill process mysqld。
- 生产环境建议统一设低：
sort_buffer_size = 256K、read_buffer_size = 128K、read_rnd_buffer_size = 256K - MyISAM 表真需要排序加速？优先加索引，而不是调
read_rnd_buffer_size；后者超过 512K 后收益极低，但内存开销线性增长 - 检查当前实际消耗：
SELECT * FROM performance_schema.memory_summary_by_thread_by_event_name WHERE event_name LIKE 'memory/sql/%' ORDER BY SUM_NUMBER_OF_BYTES_ALLOC DESC LIMIT 5;
真正难的是权衡：你没法靠公式算出“完美值”，因为 MyISAM 表的访问模式（冷热、频次、是否带排序）和 InnoDB 表的热点分布，共同决定了内存如何被撕扯。每次调整后，盯紧 SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_%' 和 free -h，比任何文档都管用。
