mysql 8.0.23+ 支持大页内存，需操作系统启用、mysql用户拥有memlock权限且innodb_buffer_pool_size为2mb整数倍；验证需查/proc/meminfo、启动日志及performance_schema状态。
确认系统是否支持大页内存
MySQL 8.0.23+ 支持大页内存（Large Pages），但前提是操作系统已启用且 MySQL 有权限使用。Linux 下需检查 /proc/meminfo 是否存在 HugePages_Total 非零值：
cat /proc/meminfo | grep -i huge
若输出为 HugePages_Total: 0，说明未配置；若为正数（如 512），还需验证 MySQL 进程能否锁定这些页——这要求 mysql 用户拥有 memlock 权限。
- 常见错误现象：
mysqld启动日志中出现Failed to set large page memory lock或Large page support disabled - 必须操作：在
/etc/security/limits.conf中为mysql用户添加两行
mysql soft memlock unlimited<br>mysql hard memlock unlimited
注意：修改后需重启 MySQL 所在的 shell 会话或整个服务，ulimit -l 应返回 unlimited 或具体数值（如 1048576 KB）。
配置 my.cnf 启用大页并校验参数对齐
大页支持由 large_pages 全局开关控制，但它只是“允许使用”，真正生效还需配合 innodb_buffer_pool_size 的整页对齐。MySQL 8.0 默认使用 2MB 大页（x86_64），所以缓冲池大小必须是 2MB 的整数倍——否则会静默降级回普通页，且不报错。
- 必须设置：
large_pages = ON（写在[mysqld]段） - 必须校验：
innodb_buffer_pool_size值是否能被2 * 1024 * 1024整除。例如设42949672960（40GB）→ 40 × 1024³ ÷ (2 × 1024²) = 20480，可整除；而42949672961就不行 - 容易踩的坑：用
40G这类带单位的写法时，MySQL 内部会按字节换算，但某些版本解析存在精度偏差；建议统一用字节数或明确写40G并启动后立刻查SHOW VARIABLES LIKE 'innodb_buffer_pool_size'确认实际值
验证大页是否真正启用
不能只看配置文件写了 large_pages = ON，要从三个层面交叉验证：
- 启动日志：grep
large page，应出现类似Using large page memory allocation (2097152 bytes) - 运行时状态：执行
SELECT * FROM performance_schema.global_status WHERE VARIABLE_NAME = 'Innodb_buffer_pool_pages_total';，再对比cat /proc/$(pidof mysqld)/status | grep -i hugetlb，若hugetlb_pgalloc> 0 说明已分配大页 - 性能信号：开启前后对比
Innodb_buffer_pool_read_requests和Innodb_buffer_pool_reads，命中率无变化但sys.dm_os_memory_clerks类似指标（Linux 下对应/proc/meminfo中HugePages_Free下降量）应与缓冲池大小匹配
特别注意：Windows 平台不支持 MySQL 的大页内存特性，该功能仅限 Linux + x86_64；ARM64 或部分云厂商定制内核可能禁用 HUGETLB，需提前确认。
为什么开了 large_pages 却没效果
最常被忽略的是内存碎片和预留机制。即使 HugePages_Total 是 512，若系统启动后已有其他进程占用了连续 2MB 块，MySQL 初始化时可能只能分配到 0 个大页。
- 解决方案：在 MySQL 启动前，用
echo 512 > /proc/sys/vm/nr_hugepages预留（需 root），并确保vm.nr_hugepages在/etc/sysctl.conf中固化 - 另一个隐藏条件：MySQL 必须在
mysqld_safe或 systemd 服务中以真实用户身份启动，而非通过容器默认的root→mysql切换——后者常丢失memlock能力 - 调试命令：
strace -e trace=munmap,mmap -p $(pidof mysqld) 2>&1 | grep -i huge可直接看到 mmap 是否请求了MAP_HUGETLB标志
大页不是“开就变快”的银弹。它减少 TLB miss，对高并发随机访问场景收益明显，但若业务以顺序扫描为主，或缓冲池本身远小于物理内存，收益可能微乎其微。上线前务必在压测环境中对比 QPS、P99 延迟和 perf stat -e dTLB-load-misses 指标。
