低内存服务器完成大表ALTER操作耗时为何仅为高内存服务器一半？

这是个挺反直觉的现象对吧？结合你给出的服务器配置和场景，我梳理了几个最可能的原因：

• 大Buffer Pool引发的集中式脏页刷新阻塞
  Server A给Buffer Pool分配了96GB（128GB × 75%），但要处理的表是220GB——远超出Buffer Pool的容量。执行ALTER时，InnoDB会持续将数据页读入Buffer Pool并修改为脏页。由于Buffer Pool空间充足，脏页会累积到很高比例（比如默认的innodb_max_dirty_pages_pct阈值）才触发刷写，此时大量脏页会集中写入磁盘，严重抢占ALTER操作所需的IO资源，直接拖慢整体速度。
  而Server B的Buffer Pool仅16GB，脏页很快就会达到刷新阈值，刷脏线程会持续小批量写回脏页，不会出现集中式IO阻塞，ALTER的IO操作能更顺畅地推进。

• 多CPU核心的利用效率瓶颈
  你提到Server A是16核，但ALTER TABLE操作（尤其是非在线ALTER，或部分版本的InnoDB在线ALTER）并不总能高效利用超多核心。过多的核心反而可能带来额外的线程上下文切换开销，或是InnoDB的线程调度机制在核心数过多时出现瓶颈。而Server B的CPU核心数应该更少（毕竟除内存和Buffer Pool外其余配置相近），ALTER线程能更高效地占用CPU资源，减少不必要的调度损耗。

• 复制活动预热了磁盘缓存
  Server B在执行ALTER时还有复制活动，复制通常是持续的顺序读写操作，这会提前预热操作系统的磁盘Page Cache，激活磁盘的读写性能。当ALTER读取220GB表数据时，大量数据已经在系统缓存中，无需频繁发起物理磁盘读取，自然速度更快。而Server A没有其他活动，磁盘缓存是空的，ALTER需要从头读取所有数据，物理IO的开销大得多。

• Buffer Pool与系统缓存的资源竞争
  Server A的Buffer Pool占了75%的内存，留给操作系统Page Cache的空间仅32GB。ALTER操作不仅依赖InnoDB的Buffer Pool，也会用到系统磁盘缓存。当Buffer Pool占用过多内存时，系统缓存空间不足，大量数据只能通过InnoDB Buffer Pool读取，而InnoDB缓存在大表全量扫描场景下的效率，往往不如操作系统Page Cache的顺序读优化。
  相反，Server B的Buffer Pool仅占16GB，剩余48GB都留给了系统缓存，大表ALTER的顺序读能充分利用系统缓存，读取速度大幅提升。

内容的提问来源于stack exchange，提问作者user3299633