MySQL启动失败的“Too many open files”错误需同步调整三层限制：系统全局fs.file-max、systemd服务级LimitNOFILE、MySQL内open_files_limit，缺一不可。
Too many open files 错误直接导致 MySQL 启动失败，不是配置没生效，而是 OS 层和 MySQL 层的文件句柄限制都没对齐。必须两层都调，缺一不可。
检查当前 ulimit 限制是否过低
MySQL 启动时读取的是启动它的 shell 进程的 ulimit -n 值，不是你登录终端的值。如果用 systemctl 启动，它默认继承 systemd 的限制（通常是 1024），和你手动 ulimit -n 65535 没关系。
验证方法：
- 查看 mysqld 进程实际生效的限制：cat /proc/$(pgrep mysqld)/limits | grep "Max open files"
- 如果 MySQL 没在跑，先用 sudo systemctl show --property=LimitNOFILE 看 systemd 全局限制
- 或临时测试：用 sudo -u mysql sh -c 'ulimit -n; exec mysqld --defaults-file=/etc/my.cnf --console'
常见坑：
- 直接在 /etc/rc.local 里写 ulimit -n 65535 对 systemd 服务无效
- /etc/security/limits.conf 对 root 启动的服务（如通过 systemctl）默认不生效，除非启用 PAM 且配置了 session required pam_limits.so
正确设置 systemd 服务级 ulimit
对使用 systemd 管理的 MySQL（绝大多数现代发行版），必须改 service 单元配置，不能只改 limits.conf。
操作步骤：
- 创建覆盖目录：sudo mkdir -p /etc/systemd/system/mysqld.service.d
- 新建配置文件：sudo tee /etc/systemd/system/mysqld.service.d/limits.conf
- 写入内容：
[Service] LimitNOFILE=65535
- 重载并重启：
sudo systemctl daemon-reload && sudo systemctl restart mysqld
注意：
- 不要用 LimitNOFILE=infinity，某些内核版本会 fallback 到 4096
- 若 MySQL 服务名是 mysql 而非 mysqld，请对应替换目录名
- 修改后务必用 systemctl show mysqld | grep LimitNOFILE 确认已加载
同步调整 my.cnf 中的 open_files_limit
open_files_limit 是 MySQL 自己向上申请的上限，它不会自动等于系统 ulimit。如果设得太小，MySQL 会主动压低自己打开的文件数，哪怕系统允许更多。
在 my.cnf 的 [mysqld] 段下添加：open_files_limit = 65535
同时建议显式控制 InnoDB 行为：innodb_open_files = 2000table_open_cache = 4096
为什么这么配：
- open_files_limit 至少要 ≥ max_connections * 5 或 max_connections + table_open_cache * 2，取大者
- innodb_open_files 控制 InnoDB 每个表空间文件的缓存上限，分区表多时必须提高，否则频繁打开/关闭 .ibd 文件
- table_open_cache 太小会导致表反复打开关闭，加剧句柄压力
验证是否生效：
- 启动后执行：mysql -e "show variables like 'open_files_limit';"
- 如果显示值仍为 1024 或 5000，说明 ulimit 没到位，或配置被其他 my.cnf 片段覆盖
别漏掉 fs.file-max 系统级总阀值
Linux 全局最大文件句柄数由 /proc/sys/fs/file-max 控制。即使单进程设到 65535，若全局总数才 32768，MySQL 启动时仍可能因竞争失败。
检查当前值：cat /proc/sys/fs/file-max
临时提升：sudo sysctl -w fs.file-max=524288
永久生效：写入 /etc/sysctl.conf 添加一行：fs.file-max = 524288
关键点：
- fs.file-max 应该 ≥ 所有高并发服务的 LimitNOFILE 之和 × 1.5
- 容器环境（如 Docker）需在宿主机和容器启动参数中分别设置，--ulimit nofile=65535:65535 仅作用于容器内进程，不影响宿主机 fs.file-max
MySQL 启动时的文件句柄问题，本质是三层嵌套限制：系统全局（fs.file-max）→ 进程级（ulimit / systemd LimitNOFILE）→ MySQL 内部（open_files_limit）。任何一层卡住，都会表现为 Too many open files，但日志里往往只报最后一层失败。最常被忽略的是 systemd 服务单元的 LimitNOFILE 配置——它不继承 shell，也不读 limits.conf，必须显式声明。
