innodb_thread_concurrency 已废弃，MySQL 5.6.27起被标记为deprecated，8.0.22彻底移除；其功能由自适应调度替代，实际并发受max_connections、innodb_read_io_threads等参数协同影响。
innodb_thread_concurrency 已失效，别再配它
MySQL 5.6.27 起该参数被标记为 deprecated，8.0.22 版本已彻底移除。你在配置文件里写 innodb_thread_concurrency = 8，MySQL 启动时会报 [Warning] InnoDB: innodb_thread_concurrency is deprecated，且完全不生效。这不是配置姿势不对，是它本身已被废弃——InnoDB 改用自适应线程调度，不再依赖这个“硬限流开关”。
真正影响并发行为的是这几个参数
实际并发能力由多层协同决定，重点看：
-
max_connections：客户端连接总数上限，超了直接报Too many connections -
innodb_read_io_threads和innodb_write_io_threads：分别控制后台读/写 IO 线程数，默认各 4，SSD 上可设为 8～16，HDD 建议保持默认或略增 -
innodb_purge_threads：清理线程数，默认 4，写密集场景（如日志表高频 INSERT）可提到 6 -
innodb_parallel_read_threads（8.0.14+）：并行扫描时单个查询可用的读线程上限，默认 4
这些值不是越大越好：比如把 innodb_read_io_threads 设到 64，但磁盘 IOPS 有限，反而加剧锁竞争和上下文切换开销。
QPS 上不去、线程卡在 Locked 状态？大概率不是线程数问题
现象是 CPU 不高、SHOW PROCESSLIST 里一堆 Locked 或 Updating，这通常不是并发线程不够，而是阻塞或锁等待导致：
- 长事务未提交，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（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 - 写密集型：把
innodb_purge_threads提到 6，同时关掉innodb_adaptive_hash_index（避免争用） - 读密集型：优先考虑加索引、优化查询，而非盲目调高
innodb_read_io_threads
最容易被忽略的一点：调参前先确认是否用了连接池、事务是否及时提交、索引是否覆盖查询字段——这些带来的性能提升，远超瞎调几个线程参数。
