【问题背景】
某天早上做活动，流量大量增长，导致大量更新库存操作失败。
操作mysql返回的错误均为“Lost Connection to mysql server”，即mysql服务端主动断开了连接，导致update操作失败。
都是在sql执行过程中返回的“Lost”，且都是update操作返回“Lost”，同一时刻的“select”操作并无异常。
都是update执行操过了1s后返回的“Lost”
【原因】
秒杀情景下是大量update同时操作同一表的同一记录
对同一记录的写操作都要加“行锁”，且有“死锁检测”，使得sql操作串行执行，有阻塞
猜测：某些请求由于等到超时了，被mysql服务关了连接
【老流程】
如果需要更新 item1（分库1）、item2（分库2）、item3（分库4）的库存
=>所有分库，每个分库上均开启一个事务
=>查询。。
=>循环处理3个item
=>=>如果该次操作以前没做过（没有seqid）继续；否则处理下一个item
=>=>更新库存
=>=>更新是否售空
=>=>插入<seqid/item>
=>所有分库，每个分库均提交事务
1）如果有一个item更新失败，回滚所有事务
2）尽量保证要不所有item都更新成功，要不都失败
1）一个事务中，sql操作太多；如果事务中有update操作，则从update操作执行到事务提交将会一直锁住操作行，因此事务越长，锁越长，性能损耗越大
2）每个分库都要等所有item更新完后才提交，增长事务时间（也就是锁时间）
【优化后】
如果需要更新 item1（分库1）、item2（分库2）、item3（分库4）的库存
=>循环在每个item所在分库对item进行处理
=>=>在分库1中开启事务
=>=>插入seq表<seq,item1>
=>=>更新库存and是否售空
=>=>提交事务
1）一次操作多个item时，不保证要不都成功，要不都失败
2）只要有sql操作失败，就返回失败
【对比】
原文：http://www.cnblogs.com/taoxinrui/p/6399691.html