先查MySQL进程实际打开的文件数：lsof -p $(pgrep mysqld) | wc -l；再对比cat /proc/$(pgrep mysqld)/limits | grep "Max open files"，若接近则确为系统限制瓶颈，否则需排查phpEnv下systemd未配LimitNOFILE、参数配置未生效或fd被PHP-FPM等服务叠加占用。
确认 MySQL 进程实际打开的文件数
别一上来就改配置，先看是不是真卡在系统限制上。lsof -p $(pgrep mysqld) | wc -l 统计当前打开的 fd 数；再用 cat /proc/$(pgrep mysqld)/limits | grep "Max open files" 查内核对这个进程的实际限制值。如果前者接近后者，说明确实是系统级瓶颈；如果前者才几百、后者却显示 1024，那大概率是 phpEnv 启动方式绕过了 limits 配置——常见于 systemd 管理的服务未显式设置 LimitNOFILE。
phpEnv 下 MySQL 的 ulimit 不生效的典型原因
phpEnv 多数基于一键脚本或自建 service 文件启动 MySQL，容易忽略 systemd 的限制继承机制：
- /etc/security/limits.conf 对 systemd 服务无效（它不读这个文件）
- 即使你在 shell 里执行 ulimit -n 65535，再手动启 mysqld，phpEnv 脚本调用的仍是原始受限环境
- 常见 service 文件路径如 /etc/systemd/system/mysqld.service 或 /usr/lib/systemd/system/mysqld.service，必须在里面加 LimitNOFILE=65535
- 修改后要 systemctl daemon-reload && systemctl restart mysqld，reload 不会重载 Limit 配置
MySQL 自身参数与系统限制的匹配关系
open_files_limit 不是“设多少就用多少”，它是 MySQL 启动时向内核申请的上限目标值，最终生效值 = min(系统允许最大值, 配置值)：
- 如果你只在 my.cnf 里写 open_files_limit = 65535，但 systemd 没配 LimitNOFILE，MySQL 会静默降级到 1024，并在 error log 写 warning
- 推荐设为系统 LimitNOFILE 的 80%～90%，比如 systemd 设了 65535，MySQL 就设 55000，留余量给 slow log、error log、socket 等其他 fd
- 验证是否生效：连上 MySQL 执行 SHOW VARIABLES LIKE 'open_files_limit';，再对比 cat /proc/$(pgrep mysqld)/limits 输出，两者应基本一致
phpEnv 场景下容易被忽略的叠加消耗点
phpEnv 通常同时跑 PHP-FPM + MySQL + Nginx，三者共用系统 fd 总额，但常被当成独立问题处理：
- PHP-FPM 子进程每个都可能打开日志、临时文件、curl socket，pm.max_children × avg_fd_per_child 可能轻松吃掉上万 fd
- MySQL 的 table_open_cache 和 max_connections 是主要 fd 消耗源，公式约为 10 + max_connections + (table_open_cache × 2)
- 若 phpEnv 使用了自定义启动脚本（如 /root/phpenv/start.sh），检查它是否用 su -c 或 sudo -u 切换用户启动 mysqld——这类调用很可能丢失父 shell 的 ulimit
- /proc/sys/fs/file-max 是全系统总上限，建议设为至少 2× 预估峰值 fd 总和（例如 MySQL 5.5w + PHP-FPM 3w → file-max ≥ 16w）
