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 泄漏。
