thread_cache_size应设为max_connections的10%–25%，如max_connections=2000时设100、500时设32；需结合Threads_created每分钟增量≤10及Threads_cached长期稳定来验证，避免内存浪费与频繁建线。
thread_cache_size设多少才不浪费内存又不频繁创建线程
MySQL 8.0中thread_cache_size控制空闲线程缓存数量，它不决定最大连接数，而是影响“新连接复用已有线程”的成功率。值太小会导致Threads_created持续上升，说明每次新连接都在新建线程；值太大则空闲线程长期驻留，白白占用thread_stack（默认256KB）内存。
推荐按max_connections的10%–25%设置，但需结合实际负载验证：
- 若
SHOW STATUS LIKE 'Threads_created'每分钟增长 > 10，说明缓存不足，可逐步加大thread_cache_size - 若
SHOW STATUS LIKE 'Threads_cached'长期接近thread_cache_size且Threads_connected波动不大，说明当前值已够用 - 生产环境常见配置：
max_connections = 2000→thread_cache_size = 100；max_connections = 500→thread_cache_size = 32
动态调整thread_cache_size后为什么没立刻生效
thread_cache_size是动态参数，执行SET GLOBAL thread_cache_size = 64后，**只对后续新连接生效**，已存在的连接和正在运行的线程不受影响。已缓存的空闲线程不会被回收，也不会新增缓存，直到它们自然退出或被复用。
验证是否起作用，要观察后续连接行为：
- 先记录当前
Threads_created值 - 施加一批新连接（如用
mysql -h 127.0.0.1 -P 3306 -u test -e "SELECT 1"循环100次） - 再查
Threads_created增量：若增幅明显小于调整前，说明缓存开始起效
和thread_handling=pool-of-threads一起用会冲突吗
会。MySQL 8.0支持两种线程模型：one-thread-per-connection（默认）和pool-of-threads（需显式启用）。而thread_cache_size**仅在默认线程模型下有效**；一旦启用thread_handling = pool-of-threads，线程池接管调度，thread_cache_size会被忽略，相关状态变量（如Threads_cached）也不再更新。
所以不要混用：
- 想用线程池：关闭
thread_cache_size相关配置，专注调thread_pool_size（建议设为CPU核心数） - 想用线程缓存：保持
thread_handling = one-thread-per-connection（默认），再调thread_cache_size - 检查当前模型：
SHOW VARIABLES LIKE 'thread_handling'
容易被忽略的关联限制：open_files_limit
每个线程对应一个文件描述符（哪怕空闲），而open_files_limit是系统级硬限制。如果thread_cache_size设得过高，加上活跃连接、表打开句柄、日志文件等，很容易触达上限，导致新连接报错Too many open files。
务必同步检查并预留余量：
- 查看当前限制：
SHOW VARIABLES LIKE 'open_files_limit' - 估算最低需求：≈
max_connections + table_open_cache * 2 + 200 - Linux系统需同步调大
/etc/security/limits.conf中mysql用户的nofile
线程缓存不是越大越好，关键看Threads_created是否可控——它才是真实反映系统开销的信号灯。
