MySQL 不报 “Too many tasks” 错误，该提示属应用层（如 Spring TaskExecutor、Tomcat 线程池）或中间件抛出；MySQL 原生仅存在 “Too many connections”（错误号1040），对应连接数超 max_connections 限制。
MySQL 不会报 “Too many tasks” 错误 —— 这个错误信息本身是假的，不是 MySQL 原生错误。你看到的大概率是应用层（比如 Java 线程池、Spring TaskExecutor、Tomcat 工作线程）或中间件（如 RocketMQ 客户端、Netty 事件循环）抛出的提示，被误认为来自 MySQL。
为什么查不到 “Too many tasks” 的 MySQL 官方错误码
MySQL 官方错误列表中没有 ER_TOO_MANY_TASKS 或类似命名；所有与连接/并发相关的标准错误都是 Too many connections（错误号 1040）。如果你在日志里搜到 “Too many tasks”，请立刻检查：
- 日志前几行是否属于 Spring Boot 的
TaskExecutionException - 堆栈里有没有
java.util.concurrent.RejectedExecutionException - 是否用了
@Async+ 自定义ThreadPoolTaskExecutor，且setRejectedExecutionHandler打印了该字样 - 是否混淆了 MySQL 的
thread_pool_size（Percona Server / MariaDB 特性）和应用自己的线程池
thread_pool_size 是什么，哪些 MySQL 能用
thread_pool_size 是 Percona Server for MySQL 和 MariaDB 的线程池参数，官方 MySQL（Oracle 版）完全不支持。它控制内部线程池中“工作线程”的数量，用于复用线程处理大量短连接，避免频繁创建销毁线程开销。
启用前提：
- 必须使用 Percona Server（如
Percona-Server-8.0.33）或 MariaDB（10.6+） - 配置中需显式开启线程池插件：
thread_handling = pool-of-threads -
thread_pool_size推荐值一般为 CPU 核心数的 1–2 倍，最大不宜超 64 - 修改后需重启 mysqld，该参数不可动态修改（Percona 8.0+ 部分版本支持
SET GLOBAL，但不推荐线上热改）
真遇到 “Too many connections”，别碰 thread_pool_size
如果你实际问题是连不上 MySQL 并看到 ERROR 1040 (HY000): Too many connections，那 thread_pool_size 完全无关——这是连接数耗尽，不是线程不够。此时应：
- 优先执行
mysqladmin -u root -p status看Threads:值是否逼近max_connections - 若已无法登录，检查是否启用了 MySQL 8.0.14+ 的管理连接：
admin_address = '127.0.0.1'+service_connection_admin权限账号 - 确认应用是否漏调
connection.close()，或用了未配置maxLifetime的连接池（如 HikariCP），导致连接泄漏 - 避免直接改
max_connections到 2000+，先看SHOW FULL PROCESSLIST里是否有大量Sleep状态连接，再调wait_timeout和interactive_timeout
真正容易被忽略的是：很多团队花时间调 thread_pool_size，却没查清错误源头是不是应用自己炸了线程池。先翻完整堆栈，定位第一行抛异常的类名，比盲目调数据库参数管用十倍。
