必须让 kernel.shmmax ≥ innodb_buffer_pool_size，否则 mysql 启动失败报 failed to create shared memory segment；因 mysql 5.7+ 默认启用系统 v 共享内存分配，innodb 缓冲池调用 shmget() 申请连续内存段，若 shmmax 小于 buffer_pool_size 则系统拒绝分配。
必须让 kernel.shmmax ≥ innodb_buffer_pool_size，否则 MySQL 启动直接失败，报 Failed to create shared memory segment 或 Cannot allocate memory。
为什么 shmmax 不够会导致 MySQL 启动失败
MySQL 5.7+ 默认关闭 innodb_use_sys_malloc（即启用系统 V 共享内存分配），InnoDB 缓冲池会调用 shmget() 申请一块连续共享内存段。如果内核限制的单段最大值 kernel.shmmax 小于你配置的 innodb_buffer_pool_size，系统拒绝分配，MySQL 进程无法初始化缓冲池，直接退出。
常见错误日志片段：
mysqld: Could not create shared memory segment
注意：这不是 MySQL 配置错误，而是内核资源限制硬性拦截，my.cnf 里再怎么调大 innodb_buffer_pool_size 都无效。
怎么算 shmmax 最小值
直接取 innodb_buffer_pool_size 的字节值，向上取整到最接近的整数即可 —— 不需要额外加 buffer，但也不能四舍五入丢精度。
- 例如
innodb_buffer_pool_size = 12G→ 换算为字节：12 * 1024 * 1024 * 1024 = 12884901888 - 所以
kernel.shmmax至少设为12884901888，写进/etc/sysctl.conf或/etc/sysctl.d/99-mysql.conf - 别用 GB 单位写（如
12G），sysctl 只认纯数字
别只改 shmmax：还要同步算 shmall（总页数），公式是 shmall = shmmax / 4096（默认 PAGE_SIZE=4096）。否则即使 shmmax 够了，shmall 不足仍可能触发 ENOMEM。
验证修改是否真正生效
很多人执行了 sysctl -p 就以为完事了，但 MySQL 是否真用上了共享内存，得看两层：
- 查内核当前值：
cat /proc/sys/kernel/shmmax，确认等于你设的数值 - 重启 MySQL 后，运行：
SELECT @@innodb_buffer_pool_size;，再执行：ipcs -m | grep mysql - 比对输出中的
bytes列 —— 它必须 ≥ SQL 查询返回的字节数。如果远小于，说明 MySQL 回退到了mmap()分配模式，根本没走 shm，问题还在
回退到 mmap 的典型原因是：要么 shmmax 仍不达标，要么 innodb_use_sys_malloc=ON 被意外开启（此时不依赖 shm），需检查 my.cnf 是否显式设置了该参数。
Ubuntu/Debian 系统容易漏掉的关键点
在 Ubuntu 20.04+ 和 Debian 12+ 上，/etc/sysctl.conf 不再被默认加载；必须把配置写进 /etc/sysctl.d/ 下的独立文件（如 /etc/sysctl.d/99-mysql.conf），且文件名要以数字开头、以 .conf 结尾。
临时生效命令：sysctl -w kernel.shmmax=12884901888，但重启后失效；永久生效必须靠 sysctl --system（或 sysctl -p 加载指定文件）+ 重启 MySQL。
最容易被忽略的是：改完 sysctl 参数后，**没重启 MySQL** —— 内核参数生效了，但 MySQL 进程是在旧参数下启动的，仍会失败。
