结论：光调MySQL配置没用，Linux内核参数不匹配会导致并发能力被系统层静默限流；net.ipv4.tcp_tw_reuse=1必须开启以加速TIME_WAIT端口复用，但需配合tcp_timestamps=1且禁用已移除的tcp_tw_recycle。
直接说结论：光调 MySQL 配置没用，Linux 内核参数不匹配，max_connections 设再高也会卡在 TCP 连接建立、TIME_WAIT 回收、内存页换出或 I/O 调度上——并发能力实际被系统层 silently throttled。
为什么 net.ipv4.tcp_tw_reuse=1 在高并发 MySQL 场景下必须开
MySQL 短连接密集型业务（如 PHP-FPM、无连接池 Java 应用）每秒新建数百连接时，大量 TIME_WAIT 状态 socket 会占满本地端口范围（默认 28232～65535），导致新连接失败，报错 Cannot assign requested address。
开启 net.ipv4.tcp_tw_reuse=1 允许内核在安全前提下复用处于 TIME_WAIT 的 socket（需满足时间戳递增），能将端口回收周期从 2×MSL（约 60 秒）压缩到毫秒级。但注意：
-
net.ipv4.tcp_tw_recycle=1已在 Linux 4.12+ 被彻底移除，且在 NAT 环境下会导致连接失败，绝对不要启用 - 必须同时设置
net.ipv4.tcp_timestamps=1（默认开启），否则tw_reuse不生效 - 搭配
net.ipv4.tcp_fin_timeout=10进一步缩短 FIN_WAIT_2 超时，减少半关闭连接堆积
innodb_buffer_pool_size 和 kernel.shmmax 必须协同调整
InnoDB 缓冲池是共享内存段，Linux 内核通过 shmmax 限制单个共享内存段最大值。若 innodb_buffer_pool_size 设为 12G，但 kernel.shmmax 仍为默认的 32MB，MySQL 启动会直接失败，报错 Cannot allocate memory 或静默崩溃。
正确做法：
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 确认物理内存：运行
free -g查看可用内存 - 设
kernel.shmmax≥innodb_buffer_pool_size，建议取值为innodb_buffer_pool_size × 1.1（留余量） - 例如缓冲池设 16G，则
kernel.shmmax = 17179869184（16GiB × 1024³ × 1.1） - 写入
/etc/sysctl.conf后执行sysctl -p生效，再重启 MySQL
vm.swappiness=0 不等于禁用 swap，但必须设为 0
MySQL 是内存敏感型服务，一旦触发 swap，单次页换入/换出延迟可达毫秒级，而 InnoDB 操作通常要求微秒级响应。设 vm.swappiness=0 并非禁止 swap 分区存在，而是告诉内核：“除非所有物理内存（包括 page cache）都已耗尽，否则绝不主动换出匿名页”。
关键事实：
- swap 分区仍可用于内核紧急情况（如 OOM 前的最后缓存回收），不会导致 crash
- 若完全删除 swap，反而可能在极端内存压力下触发 OOM Killer 杀掉
mysqld进程 - 配合
innodb_buffer_pool_size占用 70%～80% 物理内存，swappiness=0能确保缓冲池常驻 RAM，避免抖动
deadline I/O 调度器对 SSD + MySQL 的实际影响
SSD 无机械寻道，传统 cfq 调度器的“公平轮转”逻辑反而引入额外延迟；noop 虽简单，但缺乏请求合并与截止时间保障。MySQL 的随机读写混合负载（尤其是 redo log 写入 + buffer pool 页面刷脏）更依赖可预测的低延迟响应。
deadline 是折中选择：
- 它为每个 I/O 请求设读/写截止时间（默认读 500ms、写 5000ms），避免某类请求长期饿死
- 对 MySQL 的
innodb_io_capacity高配场景（如 SSD 设置为 5000），deadline能更稳定地维持吞吐 - 验证当前调度器：
cat /sys/block/nvme0n1/queue/scheduler（替换为你的设备名） - 临时切换：
echo deadline > /sys/block/nvme0n1/queue/scheduler；永久生效需加到内核启动参数或 udev 规则
真正容易被忽略的是：这些参数之间存在隐式依赖——比如调大 max_connections 后，若没同步调高 net.core.somaxconn 和 net.core.netdev_max_backlog，SYN 队列溢出就会在连接到达 MySQL 前就被内核丢弃，你根本看不到 MySQL 层的错误日志。
