一、更新超时
最近在生产上遇到了这样的一个问题，在执行到具体的update语句时，出现了SQL state [null]; error code [0]; Statement cancelled due to timeout or client request; nested exception is com.mysql.jdbc.exceptions.MySQLTimeoutException: Statement cancelled due to timeout or client request org.springframework.jdbc.UncategorizedSQLException: PreparedStatementCallback;
我们进行分析sql,该sql就是一个很正常的更新操作，按照primaryKey进行更新。并且我们在该sql上设置了jdbcTimeout=10，意思是该sql如果执行时间超过10S，就会终止执行。所以在后台服务器上抓取到了该超时日志
分析步骤：导致超时的原因是什么，该sql在执行时，因为where条件是走的主键索引，所以其会直接在该数据行加X锁，也就是说如果别的业务场景也在这一时刻做该主键行的数据更新，则该线程会被挂起。如果在10S之内A业务没有执行完，则B业务会一直等待。如果B等待超过10S之后，则会抛出该异常。当然A本身按照ID更新操作是会很快执行完毕，并释放锁的。至于A的更新有没有超时，当时也进行了业务分析，发现A是正常更新完毕的。
那还会是什么原因导致？进一步分析，A的更新操作为何会执行很久，最后分析代码，发现A的更新操作是裹在了一个大事物里，当A的update语句执行完更新操作之后，但是其他业务未执行完，所以无法进行数据的提交动作，导致A的数据行X锁无法及时释放，所以B在执行时，就会一直等待，直到超时。
怎么解：这种问题只能把A的大事物进行拆分，尽可能的拆分成小事物
二、死锁
先来看下后台死锁日志
------------------------
LATEST DETECTED DEADLOCK
------------------------
190619 8:27:17
*** (1) TRANSACTION:
TRANSACTION 374ECFC5, ACTIVE 0 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 11 lock struct(s), heap size 1248, 5 row lock(s), undo log entries 30
MySQL thread id 1271327, OS thread handle 0x7f684f63c700, query id 2386660519 10.96.200.162 JWMSusr Updating
A更新语句，按照ID去更新
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 3155 page no 5852 n bits 144 index `PRIMARY` of table `库存表` trx id 374ECFC5 lock_mode X locks rec but not gap
waiting
*** (2) TRANSACTION:
TRANSACTION 374ECDC8, ACTIVE 1 sec starting index read, thread declared inside InnoDB 500
mysql tables in use 1, locked 1
44 lock struct(s), heap size 6960, 31 row lock(s), undo log entries 237
MySQL thread id 1271277, OS thread handle 0x7f665b700700, query id 2386660596 10.96.200.168 JWMSusr Updating
B更新语句，按照ID去更新。（这里A和B是同一条SQL）
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 3155 page no 5852 n bits 144 index `PRIMARY` of table `库存表` trx id 374ECDC8 lock_mode X locks rec but not gap
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 3155 page no 5505 n bits 144 index `PRIMARY` of table `库存表` trx id 374ECDC8 lock_mode X locks rec but not gap
waiting
*** WE ROLL BACK TRANSACTION (1)
以上是我们从数据库服务器上拉取到的监测日志，可以看到，死锁的是因为X锁，而非GAP锁；首先我们来回顾下死锁产生的几种方式：
首先死锁产生的前提必须条件是：至少在两个事物以上；其次分为：1、不同表相同记录行的锁冲突；2、相同表记录行的锁冲突；3、不同索引锁冲突；4、GAP锁冲突； 从上面的监测日志，可以得知是相同表记录行的锁冲突
相同表记录行的锁冲突诱发的场景如下：
由上图我们可以看到，当两个事物包含了对方彼此的更新表时，并且是互相交叉，这样就会在MySql层会主动监测到更新闭环链路，而引发死锁告警。
如何解决：如果我们把事物进一步拆小，这样死锁可以避免。但是在实际应用场景中，我们事物管理的维度都是按照业务场景来走，并非是一个事物就只有一个更新操作。所以在实际的考量当中，应当把业务维度尽可能的缩小
同时尽可能去用主键去更新，使锁粒度达到行锁级别
