innodb_concurrency_tickets默认5000过高，高并发小事务场景应降至1000～2000；调低可强制大事务让出执行权，使小事务及时执行，缩短锁等待时长、降低死锁概率。
直接说结论：innodb_concurrency_tickets 默认 5000 太高，对高并发小事务场景是毒药；多数写密集型服务应降到 1000～2000，否则小事务会被大事务“饿死”在队列里。
为什么改 innodb_concurrency_tickets 能缓解锁争用？
这个参数不是控制锁本身，而是控制一个线程拿到 InnoDB 执行权后能连续干多少件事（比如读几行、改几个索引页）才让出 CPU。默认值 5000 意味着一个大事务可能一口气执行完全部逻辑，期间其他线程只能排队等——哪怕它们只更新一行主键，也得卡在 FIFO 队列里，间接拉长了锁持有时间与等待链。
调低它，等于强制“公平轮转”，让短事务有机会插队进来执行，从而缩短整体锁等待时长（Innodb_row_lock_waits）、降低死锁概率。
- 适用场景：秒杀扣库存、订单状态更新、高频计数器累加等大量短事务争抢热点行
- 不适用场景：批量导入、报表导出、单次更新上万行的后台任务（此时调低反而增加上下文切换）
- 注意：
innodb_concurrency_tickets只在innodb_thread_concurrency≠ 0 时生效；设为 0 时该参数被忽略
怎么判断当前值是否过高？
看 SHOW ENGINE INNODB STATUS\G 输出中 ROW OPERATIONS 区域的排队线索：
- 如果
Number of rows inserted/sorted/updated/deleted总和远低于Trx id counter增速，说明很多事务根本没机会执行 - 观察
---TRANSACTION xxx, ACTIVE xxx sec下面是否有大量mysql tables in use 1, locked 1但lock struct(s)为 0 —— 这代表事务卡在调度队列，还没真正进 InnoDB 开始拿锁 - 查
INFORMATION_SCHEMA.INNODB_TRX，若TRX_CONCURRENCY_TICKETS列长期接近或等于你设的值（比如总显示 1999/2000），说明线程频繁被截断，值可能偏小；若总显示 4999/5000，则大概率偏大
调多少合适？怎么验证？
没有通用最优值，但有安全起点和验证路径：
- 从
2000开始试（比默认 5000 降 60%），配合innodb_thread_concurrency = 16或 CPU 物理核数 × 1.5 - 每次调整后盯住三个指标至少 10 分钟：
Innodb_row_lock_waits（下降才算有效）、Innodb_threads_running（不应剧烈抖动）、Com_commit（QPS 是否稳定） - 避免一步到位调到 100：过低会导致单个 UPDATE 被拆成几十次调度，上下文切换暴涨，
show global status like 'Threads_created'会明显跳升 - 临时诊断可用
SET SESSION innodb_concurrency_tickets = 100，但切勿上线——它会让连接池里所有复用连接行为突变，引发不可控排队
最容易被忽略的联动点
单独调 innodb_concurrency_tickets 几乎没用，必须同步处理两件事：
-
innodb_thread_sleep_delay必须显式设值（比如5000），否则当线程抢不到 tickets 时会立即重试，把 CPU 打满；它和innodb_adaptive_max_sleep_delay是一对，后者必须配置（如150000）才能激活自适应休眠 - 应用层连接池要支持连接生命周期管理：HikariCP 需配
maxLifetime（建议 30min），否则旧连接带着老 tickets 值一直活着，新参数形同虚设
真正难的不是算出那个数字，而是确认你的负载确实卡在调度层——而不是 SQL 没走索引、事务没及时提交、或者硬件 IO 已饱和。先排除这些，再碰 innodb_concurrency_tickets。
