MySQL提升打开文件数限制：修改ulimit与open_files_limit详解

MySQL 文件数限制调优：为什么你改了配置却总不生效？

遇到 Too many open files 报错，第一反应往往是去改 MySQL 的 open_files_limit。但改了重启，问题依旧，甚至发现实际生效值还是可怜的 1024。这背后的原因，通常不是 MySQL 配置错了，而是系统层面的限制在“暗中作祟”。

应同时修改systemd服务LimitNOFILE和MySQL的open_files_limit配置，因为MySQL实际生效值取二者较小值，且systemd环境下/etc/security/limits.conf无效。

MySQL 启动报错 Too many open files 怎么办

这个错误的直接原因很明确：MySQL 进程打开的文件描述符超过了上限。但问题的根源，往往不在 MySQL 配置本身，而在于系统级的限制没有调整到位。你修改了 open_files_limit 却不见效，大概率是被系统的 ulimit -n 给“卡住”了——MySQL 在启动时，会取系统 ulimit -n 的值和配置文件里 open_files_limit 的较小者作为最终限制。

为什么 mysqld_safe 启动后 open_files_limit 仍是 1024

这里有个常见的误区。很多人习惯用 mysqld_safe 启动服务，却发现无论怎么设置，open_files_limit 都停留在 1024。这是因为 mysqld_safe 默认并不会继承你当前 shell 的 ulimit 设置，它启动时会重置为系统的默认 soft limit，而这个值通常就是 1024。所以，即便你在终端里执行了 ulimit -n 65535，对 mysqld_safe 来说也是无效的。

怎么验证？可以按顺序检查：

• 先看 MySQL 自己认为的生效值：SHOW VARIABLES LIKE 'open_files_limit';
• 再确认内核实际给进程的限制：cat /proc/$(pidof mysqld)/limits | grep "Max open files"
• 如果输出显示 soft=1024，那就铁证如山：系统的限制根本没穿透到 mysqld 进程。

必须同时修改 systemd 服务配置和 MySQL 配置

对于现代 Linux 发行版（如 CentOS 7+ 或 Ubuntu 16.04+），MySQL 服务通常由 systemd 管理。在这个环境下，ulimit 必须在 systemd 的 service unit 文件里显式声明，否则任何在 shell 级别做的设置都形同虚设。

正确的操作步骤是这样的：

• 第一步，编辑 systemd 服务文件：执行 sudo systemctl edit mysql（如果你的服务名是 mariadb，则相应替换）。
• 第二步，写入核心配置：在打开的编辑器中，加入以下内容：

  [Service]
  LimitNOFILE=65535

• 第三步，重启服务使其生效：执行 sudo systemctl daemon-reload && sudo systemctl restart mysql。
• 第四步，别忘了 MySQL 自身的配置：在 my.cnf 配置文件的 [mysqld] 段落下，加上一行：open_files_limit = 65535。这里有个关键点：这个值不能超过上一步在 systemd 里设置的 LimitNOFILE。

验证是否真正生效

配置做完，别急着收工。生效与否，不能只看 MySQL 的“一面之词”。SHOW VARIABLES 命令显示的，可能只是它“打算”设置的值，而内核实际分配了多少，才是决定性的。

建议进行双重验证：

• 查看进程实际限制：再次运行 cat /proc/$(pidof mysqld)/limits | grep "Max open files"。理想的输出应该是类似 Max open files 65535 65535 files，表示软硬限制都已提升。
• 排查 systemd 配置：如果 soft limit 仍然卡在 1024 或 4096，说明 systemd 的 LimitNOFILE 可能没加载成功。可以检查一下：systemctl show mysql | grep LimitNOFILE。
• 关于数值设置的提醒：将 open_files_limit 设得过高（比如超过 65535）有时反而会适得其反，MySQL 可能会自动将其下调。一个稳妥的建议是设置为 65535，或者略低一些（例如 60000），为系统本身留出一点开销余量。

说到底，MySQL 的文件数限制是一个典型的“多层覆盖”问题：系统默认值 → systemd unit 限制 → MySQL 配置项 → 内核实际分配。这就像一套组合锁，漏掉其中任何一层，open_files_limit 就很可能永远被卡在 1024。而在现代系统里，最容易被忽略的，恰恰就是 systemd 的 LimitNOFILE 配置，因为它已经不再读取传统的 /etc/security/limits.conf 文件了。