innodb_thread_concurrency 已废弃，MySQL 5.6.27+ 起弃用、8.0.22 彻底移除；其功能由自适应调度替代，实际并发受 max_connections、innodb_read_io_threads 等参数协同影响。
innodb_thread_concurrency 被废弃了，别再配它
MySQL 5.6.27+ 版本中，innodb_thread_concurrency 已被标记为 deprecated；到 MySQL 8.0.22 完全移除。现在设它没效果，还会在错误日志里报 [Warning] InnoDB: innodb_thread_concurrency is deprecated。这个参数本意是限制同时进入 InnoDB 层的线程数，但实际效果差、易误调，InnoDB 后来改用更智能的自适应调度机制替代。
真正影响并发线程行为的是这几个配置
MySQL 的实际并发能力由多层协同决定，不是单个“线程数开关”能控制的。重点关注：
-
max_connections：MySQL 实例允许的最大客户端连接数，超限会报Too many connections -
innodb_read_io_threads和innodb_write_io_threads：分别控制后台读/写 IO 线程数（默认各 4，Linux 下可设到 64） -
innodb_purge_threads：清理线程数（默认 4，高写入场景可适当增加） -
innodb_parallel_read_threads（MySQL 8.0.14+）：并行扫描时每个查询可用的读线程上限（默认 4）
这些值不是越大越好——比如 innodb_read_io_threads 设太高，在磁盘 IOPS 有限时反而加剧锁竞争；SSD 上调到 8～16 更合理，HDD 建议保持默认或略增。
高并发下线程卡住？先查是不是连接池或事务拖住了
现象：QPS 上不去、SHOW PROCESSLIST 里一堆 Locked 或 Updating 状态，但 CPU 不高。这不是线程数不够，而是阻塞或锁等待：
- 长事务未提交，导致 MVCC 快照过旧、undo 日志无法回收
- 缺少索引的
UPDATE/DELETE引发全表锁（尤其在READ-COMMITTED以下隔离级别） - 应用端连接池 maxActive 设得过大（如 Druid 默认 200），但数据库
max_connections只有 150，结果大量连接排队等连接
查法：SELECT * FROM information_schema.INNODB_TRX ORDER BY TRX_STARTED LIMIT 5; 看运行最久的事务；再结合 performance_schema.data_locks（MySQL 8.0+）定位具体锁行。
MySQL 8.0 推荐的轻量级并发调优组合
没有“通用最优值”，但可以按硬件和负载类型快速收敛配置范围：
- 普通 8 核 32G 云服务器 + OLTP 主业务：
max_connections=300，innodb_read_io_threads=8，innodb_write_io_threads=4，innodb_purge_threads=4 - 写密集型（如日志表高频 INSERT）：
innodb_purge_threads=6，关掉innodb_adaptive_hash_index（避免争用） - 读密集型（大表 JOIN 多）：
innodb_parallel_read_threads=8，确保innodb_buffer_pool_size≥ 热数据集 1.2 倍
改完必须重启 mysqld 才生效（除 max_connections 可动态 SET，但仅对新连接有效）。别信“调高就快”的直觉——很多线上慢，其实是 buffer pool 没喂饱，或者慢查询还在跑着，跟线程数根本没关系。
