MySQL 5.7 默认禁用显式 HugePages，官方明确其为实验性功能且不推荐启用；必须关闭透明大页（THP），因其动态合并机制会干扰InnoDB内存管理，导致延迟毛刺和CPU开销；验证显式大页生效需同时满足三项条件，缺一不可；真正应优先优化的是TLB压力相关配置，而非盲目开启大页。
MySQL 5.7 默认不启用显式 HugePages，且官方不推荐手动开启
MySQL 官方文档明确指出：large-pages 是一个“实验性”选项，仅在极少数特定硬件+内核+负载组合下可能带来收益，绝大多数生产环境开启后无加速，反而引入稳定性风险。这不是配置遗漏，而是有意限制——InnoDB 的内存管理逻辑（如 buffer pool 分页分配、page cleaner 调度）未针对显式大页做深度适配，innodb_use_sys_malloc = OFF 等配套设置极易出错。
透明大页（THP）必须关闭，否则会干扰 InnoDB 内存行为
Linux 默认开启的 transparent_hugepage=always 对 MySQL 是明确有害的，原因不是“大页不好”，而是 THP 的动态合并机制与 InnoDB 的内存使用模式冲突：
- khugepaged 后台线程会扫描 InnoDB 分配的匿名内存（如 buffer pool），强行合并 4KB 页为 2MB 页，导致内存碎片整理延迟毛刺
- InnoDB 按需申请/释放小块内存（例如单个索引页、undo slot），THP 的“合并-拆分”循环造成额外 CPU 开销和锁竞争
-
cat /proc/meminfo | grep AnonHugePages输出非零值（如AnonHugePages: 12288 kB）即表示 THP 正在干扰，必须处理
显式 HugePages 配置失败时静默退化，难以察觉
即使你按文档写了 large-pages（注意：my.cnf 中不能写 large-pages=1，必须是 large-pages 无等号），MySQL 启动时也不会报错，而是直接 fallback 到 4KB 页——但你从日志里根本看不到提示。验证是否生效必须同时满足：
-
@@large_pages返回1 -
SHOW ENGINE INNODB STATUS中 “BUFFER POOL AND MEMORY” 段落出现Large pages used: XXX -
grep -i huge /proc/meminfo显示已预留页数被实际使用
漏掉任一条件，就等于白配。而生产环境中最常漏的是 memlock 限制不足或 vm.nr_hugepages 预留数量算错（比如 innodb_buffer_pool_size = 24G → 至少需 12288 个 2MB 页，但忘了预留额外页给其他组件）。
真正该关注的不是“开不开大页”，而是 TLB 压力信号
大页配置本质是治标，TLB miss 才是根因。当遇到高并发下响应延迟抖动、%si（softirq）异常升高、SHOW ENGINE INNODB STATUS 中 “Pages read ahead” 高但 “Buffer pool hit rate” 也高（99%+）时，才值得排查 TLB。此时优先检查：
- buffer_pool_size 是否远超物理内存 60%（触发频繁 page-in/out）
- 是否启用了
innodb_buffer_pool_instances > 1但实例数与 NUMA 节点不匹配 -
vm.swappiness是否被设为非零值（导致 swap 活动干扰 TLB 局部性）
这些调整比折腾 large-pages 更直接有效，且无需重启 MySQL 或修改内核参数。
