MySQL无直接并发事务数上限参数，实际瓶颈在于max_connections、锁资源、日志刷盘能力与缓冲池竞争；需协同调优连接数、innodb_flush_log_at_trx_commit、innodb_buffer_pool_size及应用层事务粒度。
MySQL 本身没有“并发事务数上限”这个可直接配置的参数，真正卡住高并发写入的，是连接数、锁资源、日志刷盘能力与缓冲池竞争的综合表现。
max_connections 是第一道实际瓶颈
每个事务至少占用一个连接（哪怕复用连接，也需维持活跃状态）。默认 max_connections=151，高并发下很快耗尽，出现 Too many connections 错误。
- 先查当前值：
SHOW VARIABLES LIKE 'max_connections'; - 临时调高（重启失效）：
SET GLOBAL max_connections = 2000; - 持久化修改需在
my.cnf中加：[mysqld] max_connections = 2000 - 注意内存开销：每个连接约占用 256KB–1MB 内存，2000 连接可能吃掉 1–2GB RAM
- 配合
thread_cache_size（建议设为max_connections的 10%–20%），减少线程创建销毁开销
innodb_thread_concurrency 不要乱设
这个参数曾用于限制 InnoDB 内部并发线程数，但 MySQL 5.6.10+ 默认值为 0（即不限制），且官方已明确不推荐启用。强行设为非零值（如 8 或 16）反而会引入调度锁争用，降低吞吐。
- 确认当前值：
SHOW VARIABLES LIKE 'innodb_thread_concurrency'; - 生产环境应保持
0，让 InnoDB 自适应调度 - 若观察到
SHOW ENGINE INNODB STATUS中频繁出现SEMAPHORES等待，问题大概率不在这里，而在锁或 I/O
真正制约并发事务吞吐的是日志与缓冲区
即使连接够、线程够，innodb_flush_log_at_trx_commit 和 innodb_buffer_pool_size 才是并发写入的隐性天花板。
-
innodb_flush_log_at_trx_commit=1（默认）时，每事务都强制刷盘 redo log，SSD 也扛不住每秒上千小事务 - 改为
2后，日志只写 OS 缓冲，吞吐可提升 3–5 倍，但崩溃可能丢失 1 秒数据 -
innodb_buffer_pool_size过小（如仅 1GB）会导致频繁刷脏页，写入延迟陡增；建议设为物理内存的 70%–80% - 同时检查
innodb_log_file_size：太小会触发频繁 checkpoint，建议单个文件 ≥ 1GB（总大小 ≥ 4GB）
应用层事务控制比数据库参数更关键
数据库能支撑的并发事务数，最终由应用怎么用决定。一个长事务占着连接 + 锁 + undo log，比一百个短事务危害更大。
- 避免在事务里做 HTTP 调用、文件读写、循环计算等耗时操作
- 批量写入务必拆成小事务：每批 500–2000 行，
COMMIT后再启下一批 - Java 中禁用
autoCommit=true下的单条INSERT，改用addBatch()+executeBatch()配合手动事务 - 监控
INFORMATION_SCHEMA.INNODB_TRX，及时发现运行超 30 秒的事务
调并发事务数不是调某个开关，而是把连接、日志、缓冲、应用事务粒度这四根弦一起绷紧——松一根，整条链就打滑。最容易被忽略的是：应用没拆事务，却指望 DBA 调大 max_connections 来解决问题。
