mysql 5.7 运行不稳定大概率由 thp 引起，应永久禁用：检查 /sys/kernel/mm/transparent_hugepage/enabled 是否为 never，否则修改 /etc/default/grub 添加 transparent_hugepage=never 并重启；同时确认 defrag 也为 never，并验证 anonhugepages: 0 kb。
MySQL 5.7 在某些内核上运行不稳定，大概率是 THP（Transparent Huge Pages）在后台偷偷搞鬼，不是 MySQL 本身的问题，而是内核内存管理策略和数据库行为冲突。
检查 /sys/kernel/mm/transparent_hugepage/enabled 是否为 never
这是最直接的判断依据。MySQL 5.7 对内存分配节奏敏感，而 THP 的后台线程 khugepaged 会周期性扫描进程内存、尝试合并 4KB 页为 2MB 页——这个过程要加锁、要整理碎片、不可预测延迟毛刺。执行：
cat /sys/kernel/mm/transparent_hugepage/enabled
如果输出是 [always] 或 [madvise]，就踩中了典型陷阱。哪怕只看到 madvise，只要 MySQL 启动时没显式调用 madvise(MADV_HUGEPAGE)（它不会），THP 实际也不会生效；但 khugepaged 仍可能干扰内存分配路径。
-
never：安全，THP 完全不参与 -
madvise：仅对显式声明的内存区域启用，MySQL 不做这事，但khugepaged仍活跃，有干扰风险 -
always：高危，所有匿名内存都可能被 THP 动态介入，MySQL 延迟毛刺常见于此
为什么 echo never > enabled 临时关闭后还要改内核启动参数
临时写入 /sys/... 路径只对当前运行生效，重启即恢复默认。很多发行版（如 RHEL/CentOS 7+、Ubuntu 18.04+）默认启用 always。生产环境必须永久禁用：
- 编辑
/etc/default/grub，在GRUB_CMDLINE_LINUX末尾追加transparent_hugepage=never - 运行
sudo update-grub && sudo reboot - 重启后再次确认
cat /sys/kernel/mm/transparent_hugepage/enabled输出为never
漏掉这步，下次内核更新或机器重启，always 就回来了，MySQL 又开始间歇性卡顿。
验证是否真关掉了：看 AnonHugePages 和延迟指标
cat /proc/meminfo | grep AnonHugePages 应该输出 AnonHugePages: 0 kB。如果非零，说明仍有 THP 在后台悄悄分配大页给 MySQL 进程（即使 enabled 是 never，也可能是 defrag 没关）。
顺手检查 defrag 状态：
cat /sys/kernel/mm/transparent_hugepage/defrag
理想输出是 [never]。若为 [defer+madvise] 或 [always]，同样需一并设为 never：
echo never > /sys/kernel/mm/transparent_hugepage/defrag
再配合 perf record -e 'syscalls:sys_enter_mmap' -p $(pgrep mysqld) 观察 mmap 行为，或用 mysqlslap 测 p99 延迟，才能确认卡顿是否缓解。
别把 large-pages 和 THP 搞混
MySQL 的 large-pages 配置项（写在 my.cnf 的 [mysqld] 段，无等号）启用的是 **显式大页（hugetlbpage）**，和 THP 完全无关，甚至互斥。两者共存会导致内核行为混乱。
- 启用
large-pages前，必须先禁用 THP，否则 MySQL 启动可能失败或静默 fallback -
SHOW VARIABLES LIKE 'large_pages'显示ON≠ 生效，得看INNODB STATUS里有没有Large pages used，以及pmap -x $(pgrep mysqld) | grep "huge" - THP 是“透明”的、“自动的”、“不可控的”；hugetlbpage 是“显式的”、“预分配的”、“需权限的”
真正影响 MySQL 5.7 稳定性的，从来不是“要不要大页”，而是“能不能让内存分配行为可预测”。关掉 THP，是最小代价、最高收益的一步。
