单条 SQL 很快，实例仍可能变慢，因为大量请求竞争连接、CPU、内存、日志和存储。全局调优先找饱和资源与排队位置，不要先扩大所有参数。
Table of contents
Open Table of contents
Buffer Pool 缓存什么
Buffer Pool 是 InnoDB 的页缓存，保存索引页和数据页。命中能避免磁盘读取；被修改但尚未写回的数据页叫脏页。命中率很高也不代表健康：工作集可能小，但日志盘、CPU 或锁已经饱和。
观察脚本提供了 innodb_buffer_pool_stats 示例。至少同时看工作集大小、脏页比例、读取速率、淘汰、I/O 延迟和内存总量。专用数据库可给较大 Buffer Pool，共享容器必须给操作系统、连接和临时内存留空间。
连接数为何不是越大越好
连接池把建连成本摊薄，但每个活跃查询仍消耗线程、内存和锁资源。池过大只会把等待从应用队列推到数据库内部，增加上下文切换并放大故障。
可用 Little 定律做起点：并发在途量约等于吞吐乘平均响应时间。例如目标 500 次/秒、数据库阶段平均 20ms，平均在途约 10；再考虑峰值和事务占用做压测，而不是直接设 500 个连接。
连接池必须设置获取超时、查询/事务超时、最大生命周期和泄漏观测。超时要形成从入口到数据库逐级缩短的预算，避免下游还在工作而上游早已放弃。
I/O 与提交压力
随机读、脏页刷写、Redo 刷盘、Binlog 刷盘和备份会竞争存储。观察吞吐、队列深度、延迟分位数和 fsync，不只看磁盘使用率。批量合理提交能摊薄刷盘，但超大事务会加重 Undo、复制和恢复负担。
调优一次只改少量变量，保存基线、变更、负载与回滚条件。没有同负载前后对比的“参数优化”无法验收。
下一步
继续阅读06-15 主从复制、延迟与读写分离，理解副本带来的可用性和一致性边界。