InnoDB缓冲池过小会导致查询变慢，因热数据无法常驻内存而频繁磁盘I/O，表现为Buffer pool hit rate低于95%、Pages read ahead异常升高；建议设为物理内存50%–75%，并监控Innodb_buffer_pool_read_requests与reads比值。
为什么 innodb_buffer_pool_size 设太小会导致查询突然变慢
InnoDB 的数据和索引都靠这个缓冲池缓存，设得太小，每次查都要反复从磁盘读页，I/O 暴涨。尤其在热数据集大于缓冲池时，会出现大量 Buffer pool hit rate 低于 95% 的情况，SHOW ENGINE INNODB STATUS 里能看到频繁的 Pages read ahead 或 Pages made young 异常升高。
- 建议初始值设为物理内存的 50%–75%，但别超过 80%，留内存给 OS 和其他进程
- 动态调整需重启 MySQL（5.7+ 支持在线调大，但仅限整数倍增长，且不能缩小）
- 监控关键指标：
Innodb_buffer_pool_read_requests（逻辑读）、Innodb_buffer_pool_reads（物理读），比值越低越好 - 注意：如果实例跑着多个库/表，但只有部分表被高频访问，盲目拉高缓冲池反而可能让冷数据挤走热数据，不如配合
innodb_buffer_pool_dump_at_shutdown做热点预热
MyISAM 的 key_buffer_size 只缓存索引，不缓存数据行
这是和 InnoDB 缓冲池最根本的区别——MyISAM 把数据文件（.MYD）完全交给 OS 缓存，自己只管索引（.MYI）。所以即使你把 key_buffer_size 设得再大，对全表扫描或 SELECT * 类查询几乎没帮助；它只加速基于索引的查找、ORDER BY 和 GROUP BY 中用到索引的部分。
- 常见误判：看到
Key_reads / Key_read_requests比值高，就猛加key_buffer_size，但其实可能是索引设计不合理（比如缺失复合索引） - 若混合使用 MyISAM 和 InnoDB 表，
key_buffer_size和innodb_buffer_pool_size要分开算，别用同一块内存硬凑 - MySQL 8.0 已移除 MyISAM 默认引擎支持，新项目基本不用考虑，但存量系统升级前务必确认是否有依赖 MyISAM 特性的触发器或全文索引
如何判断当前缓冲池是否成为瓶颈
不能只看命中率数字。真正卡顿往往出现在缓冲池内部争用：比如多个线程同时申请页、刷脏页跟不上、LRU 链表分裂等。典型现象是 SHOW ENGINE INNODB STATUS 中出现 SEMAPHORES 下的 wait array 长时间非空，或 BACKGROUND THREAD 显示 flush list 积压严重。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 检查
Innodb_buffer_pool_wait_free：非零说明线程在等空闲页，缓冲池太小或刷脏太慢 - 对比
Innodb_buffer_pool_pages_dirty和Innodb_buffer_pool_pages_flushed：前者持续高于后者的 20%，说明刷脏滞后 - 启用
innodb_buffer_pool_dump_pct=25并定期 dump，可减少重启后冷启动抖动，但 dump 文件本身会占用磁盘 I/O - 注意：Percona Server 或 MariaDB 提供更细粒度的缓冲池分片统计（如
innodb_buffer_pool_instances），官方 MySQL 8.0+ 才默认开启多实例（需 ≥ 1GB 才生效）
混合引擎场景下缓存配置的常见冲突点
当一个查询 JOIN 了 InnoDB 和 MyISAM 表，MySQL 优化器可能选错驱动表，导致本该走 InnoDB 缓冲池的热数据被反复淘汰，而 MyISAM 索引又因 key_buffer_size 不足被迫频繁读盘。这时候调单个参数意义不大，必须结合执行计划看。
- 用
EXPLAIN FORMAT=JSON查看used_columns和buffer_result字段，确认哪些中间结果进了缓冲池 -
tmp_table_size和max_heap_table_size影响 JOIN 结果临时表存放位置——若超限会转成磁盘临时表（On_disk_from_memory），此时缓冲池再大也没用 - MyISAM 表的
DELAY_KEY_WRITE=ON可减少索引写入延迟，但崩溃后索引可能损坏，且该设置对 InnoDB 无效 - 最容易被忽略的是：MyISAM 表级锁 + InnoDB 行级锁混用时，长时间未提交的 InnoDB 事务会阻塞 MyISAM 表的
FLUSH TABLES WITH READ LOCK，进而影响key_buffer刷新时机
缓冲池不是越大越好，也不是调一次就一劳永逸。真正难的是在业务流量波动、数据分布偏斜、查询模式突变时，识别出到底是缓存不够、刷脏不及时，还是索引或 SQL 本身出了问题。
