InnoDB缓冲池用于缓存数据和索引页，合适容量可能减少磁盘访问，但不是越大越快。共享主机还需给PHP、系统、连接及其他服务留空间，容量判断应结合工作集、命中与I/O，而非照抄一个内存百分比。
先确认瓶颈是否与数据读取有关
收集同时间范围的数据库I/O、查询、缓冲池和整机内存指标，区分磁盘读取、锁等待和CPU计算。若慢请求主要等待外部接口，扩大缓冲池未必改善。不能只看数据库体积大，就推断必须把整个库全部放进内存才算专业配置。
区分工作集与全部历史数据
经常访问的表页和索引构成的工作集，可能与总库容量差异很大。历史日志、旧修订和冷数据不一定同频读取。观察典型业务时段的缓存与磁盘行为，不用一次重启后的冷状态，直接与长时间运行后的另一个配置作结论性比较。
按整机与运行版本调整
缓冲池的管理方式、调整能力和相关参数随实现与版本变化，MySQL与MariaDB也不能完全套用。保存配置并安排可回退窗口，考虑其他服务峰值和数据库连接开销。不要为了数据库缓存把整机逼到持续交换，反而增加所有站点延迟。
用同类负载验证真实收益
比较调整前后相同业务的响应、I/O、错误和内存余量，给缓存预热留出解释空间。若收益不明显，继续检查查询和索引，而不是无限增大参数。最终记录选择依据和未覆盖负载，避免一个站点的经验被不加条件地推广到所有服务器。
关键区别
缓冲池：缓存InnoDB页；不解决所有慢请求。
数据库总量：包括大量冷数据；不等于实时工作集。
整机内存：由多个服务共享；不能只按单项占满。
怎样确认处理到位
代表性业务在资源充足条件下表现改善，数据库I/O和错误可解释，PHP与其他服务没有被挤压，配置和回退记录明确。
容易误判的边界
不提供适合所有主机的固定比例；缓冲池命中率也不能独立证明查询设计或网站整体体验已经最优。
