mysql报too many open files需同时调操作系统和mysql层:先用lsof和/proc/pid/limits确认是否真触顶,systemd启动须改limitnofile,my.cnf中open_files_limit应设为系统值的80%~90%,表多加dts校验易爆满。

MySQL 报 Too many open files 不是配置写错了,而是系统给它的文件描述符(fd)上限太低,或者它自己没管住手——开了太多文件又不关。必须同时调操作系统层和 MySQL 层,漏一层就白忙。
怎么确认真触顶了,还是 MySQL 自己在瞎开
别一看到报错就改配置。先看进程实际开了多少、系统允许多少:
-
lsof -p $(pgrep mysqld) | wc -l—— 统计当前 mysqld 进程打开的 fd 总数 -
cat /proc/$(pgrep mysqld)/limits | grep "Max open files"—— 查它真正继承到的 soft/hard 限制(注意:这和你终端里ulimit -n的值可能完全不同) - 如果第一项数字接近或等于第二项的 soft limit,说明系统层确实卡死;如果第一项才 2000,而 soft limit 是 65536,那大概率是 SQL 层问题:比如未关闭游标、大排序生成大量临时文件、或 DTS 校验时批量打开几万张表的
.frm文件
systemd 启动的 MySQL 必须改 LimitNOFILE
Ubuntu/CentOS/RHEL 现代发行版默认用 systemd 拉起 mysqld,它完全不读 /etc/security/limits.conf。只改那个文件,等于没改。
- 新建目录和文件:
/etc/systemd/system/mysqld.service.d/limits.conf - 写入:
[Service] LimitNOFILE=65536
- 执行
sudo systemctl daemon-reload && sudo systemctl restart mysqld - 验证:
sudo systemctl show mysqld | grep LimitNOFILE,确保输出是 65536
my.cnf 里的 open_files_limit 要设得比系统限制小一点
open_files_limit 不是强制值,是 MySQL 向系统“申请”的目标值。它最终取 min(系统允许最大值, 配置值)。设得比系统限制还高,MySQL 会静默下调,并在 error log 写 warning,但不会报错中断启动。
- 在
/etc/my.cnf的[mysqld]段下显式写:open_files_limit = 55000(建议设为 systemdLimitNOFILE值的 80%~90%,留出空间给 error log、slow log、socket、临时表等) - 不要写
0或空值,也不要带单位(如65536k) - 重启后进 MySQL 执行:
SHOW VARIABLES LIKE 'open_files_limit';,应返回 ≥55000
容易被忽略的复杂点:表多 + DTS 校验直接爆满
当库中有 7 万+ 张表,又跑 DTS 全库结构校验时,MySQL 会在单个事务里批量打开所有表的元数据文件——每个表至少占 1 个 fd。这时哪怕你把 open_files_limit 和 LimitNOFILE 都设到 65536,也可能瞬间打满。这不是配置不到位,是设计模式和使用场景叠加导致的隐性瓶颈。遇到这种情况,得拆解校验范围,或临时调高限制并监控 fd 泄漏。











