必须同步配置systemd的limitnofile、内核级fs.file-max及my.cnf中open_files_limit，三者缺一不可；否则mysql会静默降级至1024，且仅重启服务（非reload）并双重验证/proc/pid/limits与show variables才有效。
直接改 systemd 的 LimitNOFILE，否则 MySQL 会静默降级到 1024，哪怕你 my.cnf 里写了 65535 也没用。
查清楚 MySQL 进程实际拿到多少文件描述符
别只看 ulimit -n 或 SHOW VARIABLES LIKE 'open_files_limit'，它们可能完全不一致。真正生效的是进程启动时继承的系统限制：
-
lsof -p $(pgrep mysqld) | wc -l—— 当前真正在用的 fd 数量 -
cat /proc/$(pgrep mysqld)/limits | grep "Max open files"—— 系统实际允许它的上限（soft:hard）
如果前者远小于后者（比如 300 vs 65535），问题不在系统限制，而在 SQL 层：没释放游标、ORDER BY 生成大量磁盘临时表、JOIN 字段类型不匹配导致索引失效等。
systemd 下必须显式配 LimitNOFILE
/etc/security/limits.conf 在 systemd 环境下默认不生效——MySQL 启动时不读它，除非你额外启用了 pam_limits.so 且服务没覆盖限制。唯一可靠的方式是改 service 文件：
- 运行
systemctl cat mysqld找到真实 unit 路径（常见于/usr/lib/systemd/system/mysqld.service或/etc/systemd/system/mysqld.service.d/override.conf） - 在
[Service]段末尾加：LimitNOFILE=65535（建议设为整数，不要带k或M） - 执行
systemctl daemon-reload && systemctl restart mysqld - 重启后立刻验证：
cat /proc/$(pgrep mysqld)/limits | grep "Max open files"输出值必须等于你设的数字
若仍是 1024，说明 service 文件改错位置、被其他同名 unit 覆盖，或 mysqld_safe 包装器干扰（MySQL 8.0+ 建议禁用 mysqld_safe，直跑 mysqld）。
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
open_files_limit 在 my.cnf 里怎么设才有效
这个参数不是“配置即生效”，而是 MySQL 启动时向系统申请的**目标值**，最终取以下三者最小值：
- 你写的
open_files_limit值 10 + max_connections + (table_open_cache * 2)- 系统实际允许的最大值（即
/proc/$pid/limits里的 hard limit）
所以建议：
-
open_files_limit设为LimitNOFILE值的 80%～90%，留余量给 error log、slow log、socket 等其他 fd - 同时调大
table_open_cache和max_connections时，要同步评估open_files_limit是否够用 - 设得比系统限制还高，MySQL 会自动下调，并在错误日志写 warning，但不会报错中断
验证是否真生效：重启后进 MySQL 执行 SHOW VARIABLES LIKE 'open_files_limit';，再对比 cat /proc/$(pgrep mysqld)/limits，两者应接近（允许差几十个，因 MySQL 自身也占少量 fd）。
Docker 或云主机环境的特殊处理
容器和托管环境有额外约束：
- Docker 运行 MySQL：必须在
docker run时加--ulimit nofile=65536:65536，宿主机的ulimit不传递给容器 - 阿里云/华为云等云主机：默认
ulimit -n可能已是 65535，但 systemd 仍需显式配LimitNOFILE，否则 MySQL 进程拿不到 - MySQL 8.0.19+：直接以操作系统限制为准，不再按旧公式计算，所以系统层配置失误会导致更隐蔽的降级
最容易被忽略的点：改完配置没 daemon-reload，或改了 limits.conf 却没重新登录 session，MySQL 进程根本没读到新限制——所有操作都必须重启 mysqld.service，reload 无效。
