上周帮一个朋友排查线上问题，他们的订单系统每到高峰期就报错，日志里全是死锁和连接超时。我一看代码，好家伙，每个请求进来都new一个数据库连接，用完也不关，线程池里二十个线程同时往里怼。这场景我太熟了，多线程并发访问MySQL，踩坑的人前赴后继，今天就把这些坑掰开揉碎了说给你听。
第一个坑就是连接管理。很多人觉得用连接池就万事大吉，其实不然。连接池大小设多少？设大了，MySQL默认连接数151，你设200个连接，直接报"Too many connections"。设小了，比如就5个，高峰期一个查询要等3秒，用户全跑了。更坑的是连接泄漏，代码里try-catch没写finally关闭连接，一次异常就把连接池吃干抹净。我见过最离谱的案例，连接池配了50个，跑了一晚上，第二天早上只剩3个可用，其余全部泄漏。排查半天，发现是某个查询超时后没走finally块。
再说事务隔离级别。MySQL默认是Repeatable Read，这个级别下，两个事务同时更新一行，后提交的会一直等，直到前一个提交或回滚。如果你在事务里先select再update，两个线程同时操作同一条记录，大概率会死锁。有个经典场景：用户下单扣库存，代码里先查库存再更新库存，两个请求同时进来，都查到了库存是10，然后同时更新，一个成功一个死锁。解决办法很简单，直接update语句带条件判断，或者用select for update，别先查后更。
索引失效也是重灾区。多线程并发下，索引失效的后果被无限放大。比如你在where条件里用了函数，或者隐式类型转换，明明有索引却全表扫描。两个线程同时全表扫描，MySQL的锁粒度直接到表级，后面的查询全堵住。我见过最坑的案例，订单表按用户id建了索引，但查询时用了，userid是int类型，字符串和数字比较，索引直接失效。并发一上来，数据库CPU直接飙到100%。
连接超时和读写超时设置不当，这个坑埋得特别深。MySQL的waittimeout默认8小时，你连接池里的连接超过这个时间没活动，MySQL主动断开。但连接池不知道啊，还拿着这个死连接去执行查询，直接报"Communications link failure"。还有socketTimeout，不设的话，一个慢查询能把你整个线程池拖死。我建议连接池的testOnBorrow开启，每次取连接时验证一下有效性，虽然有点性能损耗，但比报错强。
死锁这个坑，十个并发问题九个跟它有关。死锁出现的条件很苛刻，但一旦出现就是灾难。最典型的场景是：事务A先更新表1再更新表2，事务B先更新表2再更新表1。两个事务同时提交，互相等对方释放锁，MySQL的InnoDB引擎检测到死锁后，会回滚代价较小的事务。但你知道哪个事务代价小吗？MySQL是自己算的，有时候回滚的恰恰是你不想回滚的那个。解决死锁，一是保持事务短小，二是统一加锁顺序，三是用设置超时时间，别无限等下去。
还有个容易被忽略的坑，就是连接池的初始化大小和最大空闲时间。很多框架默认的连接池初始是0，你第一个请求进来才创建连接，并发一上来，连接池疯狂创建连接，数据库端压力巨大。我见过一个案例，连接池初始10，最大50，但并发突然从100涨到1000，连接池创建连接的速度跟不上，大量请求排队等待，直接把MySQL打挂了。正确的做法是，初始大小和最小空闲数保持一致，预热连接，别让连接池在高峰期突然扩张。
分库分表后的跨库查询，这个坑更隐蔽。多线程并发下，你以为把数据拆到多个库就没事了，但跨库join、跨库事务，这些操作在并发下会引发分布式事务问题。我见过一个团队，把订单表拆成32个分表，但查询的时候用了跨表聚合，结果多个线程同时查询，每个线程要挨个遍历32张表，响应时间直接翻倍。更麻烦的是，如果某个分表连接超时，整个查询就挂了，而且很难定位是哪张表出了问题。
说说读写分离。很多团队搞主从复制，读走从库，写走主库，觉得这样并发就解决了。但主从延迟这个坑，能把人坑到怀疑人生。你写完主库，立刻去从库读，读不到刚写的数据，因为复制是异步的。并发越高，延迟越大。我见过一个电商项目，用户下单后跳转订单页，订单页从从库读，结果刚下的单显示不出来，用户疯狂点刷新，越刷越看不到，投诉到客服。解决办法要么强制走主库，要么用缓存，要么用半同步复制，别天真的以为读写分离就万事大吉。
这些坑我基本都踩过，有些是帮别人擦屁股，有些是自己踩的。多线程并发访问MySQL，本质上是资源竞争和一致性的问题，没有银弹，只有根据业务场景不断调整优化。你踩过几个？可以在评论区聊聊，说不定你的案例能帮其他人避开一个更大的坑。
