“can't create a new thread (errno 11)”根源在系统级线程限制，需查cat /proc/pid/limits | grep "max processes"确认mysqld进程实际限制，优先调整systemd的tasksmax（如tasksmax=65535），再同步优化mysql的max_connections与thread_cache_size。
查当前 MySQL 进程的线程数限制
错误 Can't create a new thread (errno 11) 表面是 MySQL 报错，但根源往往在操作系统对单个进程能创建的线程数做了硬性限制。直接看 MySQL 进程当前生效的限制最可靠：
- 先获取 mysqld 进程 PID：
pidof mysqld或ps -ef | grep mysqld | grep -v grep - 再查其 limits：
cat /proc/<code>PID/limits | grep "Max processes"（注意替换PID） - 若输出类似
Max processes 10 10 processes，说明已被卡死在极低值，基本可锁定问题
临时提高限制（不重启 MySQL）
适合快速验证或紧急恢复，但重启后失效。关键点是：必须对 mysqld 进程本身生效，不是改 shell 的 ulimit 就完事：
- 用
echo直接写入 procfs（需 root 权限）：echo -n "Max processes=65535:65535" > /proc/<code>PID/limits - 执行后立刻检查是否生效，再试连接；若仍报错，说明还有其他层限制在起作用
- 此操作不触发 MySQL 重启，但部分旧内核（如 3.10 之前）可能拒绝写入，需配合 systemd 调整
永久生效的三种方式及优先级
systemd 环境下（CentOS 7+/Ubuntu 16.04+），limits.conf 常常被绕过，真正起效的是 systemd 的资源控制配置：
- 首选改
/etc/systemd/system.conf：取消注释或新增DefaultTasksMax=65535，然后运行systemctl daemon-reload - 次选改 MySQL 服务单元文件：
/etc/systemd/system/mysqld.service.d/override.conf中加[Service]\nTasksMax=65535，再systemctl daemon-reload && systemctl restart mysqld -
/etc/security/limits.d/90-nproc.conf仅对通过 login shell 启动的进程有效；若 mysqld 由 systemd 直接拉起，该配置大概率不生效
别漏掉 MySQL 自身的线程相关参数
系统限制调高后，如果连接数仍暴涨到临界点，MySQL 内部参数也会成为瓶颈：
-
max_connections设太高（比如 10000+），而thread_cache_size过小（默认 0 或 2），会导致频繁创建销毁线程，加剧系统压力 - 建议搭配调整：
thread_cache_size可设为max_connections / 8左右（上限一般不超过 16），避免线程抖动 - 检查当前线程使用情况：
SHOW STATUS LIKE 'Threads_%';关注Threads_created是否持续飙升——这是线程缓存未起效的明确信号
TasksMax 默认值（512 或 1024），它比 ulimit 更底层、更顽固。哪怕 ulimit -u 显示 65535，只要 systemd 没放开 TasksMax，mysqld 进程照样被掐在几百个线程。
