mysql 8.0.22+ 已彻底移除 innodb_thread_concurrency，调参无效；真实索引竞争多由长事务、锁争用、索引缺失或事务设计不当导致，应优先排查 innodb_trx、data_locks 和执行计划。
别再调 innodb_thread_concurrency 了——它在 MySQL 8.0.22+ 已彻底移除，调了也不生效。
查配置前先确认 MySQL 版本和参数状态
很多人一看到“高并发下索引竞争严重”，第一反应是去改 innodb_thread_concurrency，结果发现改完没变化，或者 SHOW VARIABLES 里值对但性能毫无改善。根本原因是：
- MySQL 5.6.27 起该参数已被标记为
deprecated，启动时会报[Warning] InnoDB: innodb_thread_concurrency is deprecated - MySQL 8.0.22 及以后版本已完全删除该参数，配置文件里写它会被忽略，
SET GLOBAL会直接报错 - 你看到的“索引竞争严重”，大概率不是线程数限制问题，而是锁争用、索引设计或事务行为导致的
真正影响索引并发性能的几个关键参数
索引操作（尤其是 UPDATE/DELETE）卡在“Locked”状态，本质是行锁/间隙锁等待，而非线程池满了。此时要看的是底层资源调度能力：
-
innodb_read_io_threads和innodb_write_io_threads：控制后台 IO 线程数，默认各 4。SSD 上可设为 8～12，但 HDD 不建议盲目提高，否则加剧锁竞争 -
innodb_purge_threads：清理 undo 日志的线程数。写密集场景（如日志表高频插入）设为 6 能缓解 purge 堵塞，避免 MVCC 快照过旧拖慢查询 -
innodb_adaptive_hash_index：MySQL 5.7+ 默认开启，但在高并发 UPDATE 场景下，它会成为 CPU 热点。建议 OLTP 写多场景中设为OFF -
max_connections：和应用连接池不匹配时，大量连接排队等空闲连接，表现为“看起来有并发，实际都在等”
排查索引竞争的真实路径
不要凭感觉调参。先运行这几条命令定位瓶颈类型：
- 看当前阻塞源头：
SELECT * FROM information_schema.INNODB_TRX ORDER BY TRX_STARTED LIMIT 5;—— 找出最久未提交的事务 - 查具体锁在哪一行（8.0+）：
SELECT * FROM performance_schema.data_locks;—— 看是不是某张表的主键或二级索引被反复争抢 - 检查是否缺索引导致锁升级：
EXPLAIN FORMAT=TREE对慢UPDATE WHERE语句，确认是否走了全表扫描 - 观察锁等待比例：
SHOW ENGINE INNODB STATUS\G，重点关注SEMAPHORES和TRANSACTIONS部分的lock wait计数
最容易被忽略的一点：事务长度比线程数更重要
一个长事务持有锁几十秒，比 100 个短事务更致命。哪怕你把所有并发参数都设到理论最优，只要存在未提交事务，后续所有涉及相同索引范围的操作都会排队。真实生产中最常见的“索引竞争”，往往来自：
- 应用端忘记
commit或异常后没rollback - 业务逻辑中嵌套了耗时 RPC 或文件读写，把数据库事务拖长
- 批量导入脚本用单事务包几万行，期间其他业务全卡住
这类问题，调任何线程参数都无效。必须从 TRX_STARTED 时间、应用链路追踪、以及 wait_timeout 配合连接池 idle timeout 共同治理。
