应同时修改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 默认不继承 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+）用 systemd 管理 mysqld，ulimit 必须在 service unit 文件里显式声明，否则任何 shell 级设置都无效。
- 编辑服务文件：
sudo systemctl edit mysql（或mariadb，视实际服务名而定） - 写入以下内容：
[Service] LimitNOFILE=65535
- 重启服务：
sudo systemctl daemon-reload && sudo systemctl restart mysql - 再在
my.cnf的[mysqld]段加：open_files_limit = 65535（注意：该值不能超过LimitNOFILE）
验证是否真正生效
别只看 SHOW VARIABLES，它可能只是“声称”要设这么大；关键看内核给进程实际分配了多少。
- 查进程 limits：
cat /proc/$(pidof mysqld)/limits | grep "Max open files"，输出应类似Max open files 65535 65535 files - 如果 soft limit 仍卡在 1024 或 4096，说明 systemd 的
LimitNOFILE没加载成功，检查systemctl show mysql | grep LimitNOFILE -
open_files_limit设太高（如 > 65535）反而可能被 MySQL 自动下调，建议设为 65535 或略低（如 60000），留出系统开销余量
open_files_limit 就永远卡在 1024。最常被忽略的是 systemd 的 LimitNOFILE，它不像旧版 mysqld_safe 那样读取 /etc/security/limits.conf。 
