MySQL 5.7 启用 HugePages 需禁用 THP、预分配足够大页、配置 memlock 权限及 my.cnf 中写 large-pages（无等号），否则静默退化为 4KB 页；验证须查 @@large_pages=1 和 INNODB STATUS 中“Large pages used”。
启用大页内存（HugePages）对 MySQL 5.7 的性能提升不是“开箱即用”的加速器，而是针对高内存压力、高并发 OLTP 场景下 TLB 命中率和内存分配路径的精准优化；不配好反而可能引入干扰，甚至被 Transparent Huge Pages（THP）反向拖慢。
MySQL 5.7 为什么特别吃 TLB 命中率
5.7 大量依赖 InnoDB Buffer Pool，且默认将内部临时表也切到 InnoDB 引擎。这意味着更频繁的页访问、更密集的虚实地址映射——尤其是当 buffer_pool_size 超过几十 GB 时，4KB 页面会生成海量页表项。TLB（Translation Lookaside Buffer）容量有限，大量 miss 会触发昂贵的多级页表遍历，直接抬高 CPU cycles / query。2MB 大页能把同样内存映射所需的 TLB 表项减少 512 倍，显著压缩 TLB miss 率。
关键点在于：这不是“理论加速”，而是 5.7 在高并发下更容易暴露 TLB 瓶颈。比如你看到 SHOW ENGINE INNODB STATUS 中 Buffer pool hit rate 很高（99%+），但响应延迟毛刺明显、sysstat 显示 %si 或 %st 异常偏高，就该怀疑 TLB 或内存分配路径问题。
必须禁用 THP，否则 HugePages 反而失效
Linux 默认启用的 transparent_hugepage=always 或 madvise 与显式配置的 HugePages 是互斥机制。MySQL 5.7 不调用 madvise(MADV_HUGEPAGE)，所以 THP 对它基本无效；但后台线程 khugepaged 仍会扫描匿名内存、尝试合并页面，干扰 InnoDB 自己的内存分配节奏，导致延迟抖动。
- 检查当前状态：
cat /sys/kernel/mm/transparent_hugepage/enabled—— 输出含[always]或[madvise]就必须处理 - 临时关闭（仅本次生效）：
echo never > /sys/kernel/mm/transparent_hugepage/enabled - 永久关闭（生产必备）：在
/etc/default/grub的GRUB_CMDLINE_LINUX末尾加transparent_hugepage=never，再运行sudo update-grub && sudo reboot - 验证是否真关掉：
cat /proc/meminfo | grep AnonHugePages必须输出AnonHugePages: 0 kB
如何正确配置显式 HugePages 给 MySQL 5.7
显式 HugePages 需手动预留、锁定，MySQL 启动时通过 innodb_use_sys_malloc = OFF + innodb_large_prefix = ON（非必需但建议）等配合使用。但最易错的是计算和权限：
- 先算需求数量：假设
innodb_buffer_pool_size = 24G，2MB 每页 → 至少需要24 * 1024 / 2 = 12288个 huge page - 设置预留：
echo 12288 > /proc/sys/vm/nr_hugepages（临时）或写入/etc/sysctl.conf：vm.nr_hugepages = 12288 - MySQL 用户必须有锁定内存权限：在
/etc/security/limits.conf加两行：mysql soft memlock unlimitedmysql hard memlock unlimited - 重启 mysqld 前确认：
grep -i huge /proc/meminfo中HugePages_Free≥ 所需数，且HugePages_Rsvd> 0
漏掉 memlock 权限，MySQL 启动时日志里会出现 InnoDB: HugeTLBFS option is not used，但不会报错退出——它会默默退回 4KB 页，你完全感知不到失败。
什么时候其实不需要 HugePages
如果你的 MySQL 5.7 实例 innodb_buffer_pool_size ≤ 8GB，或者服务器总内存 ≤ 32GB，或者业务以低并发、长事务、批量导入为主（而非高频短 query），那么 HugePages 带来的收益极小，反而增加运维复杂度。此时优先优化 tmp_table_size 和 max_heap_table_size 同步、关闭 performance_schema、调小 table_open_cache，见效更快。
真正起作用的从来不是“开了大页”，而是你关掉了 THP、锁住了内存、让 InnoDB 的地址映射稳定在可预测的路径上——这在 5.7 高负载下，比任何单点参数调优都更底层、更不可替代。
