故事背景
今天朋友说操作mysql超时了，我首先想到的是环境的问题。我问是不是数据源配错了，他给我的答案是否定的。然后查了下日志：java.sql.SQLException: Lock wait timeout exceeded; try restarting transaction。跟踪到是下面SQL导致的表锁 SELECT * FROM t_cms_promotion t WHERE t.pro_des = #{description} FOR UPDATEinnodb锁机制
innodb默认是行锁，前提条件是建立在索引之上的。如果筛选条件没有建立索引，会降级到表锁。即如果where条件中的字段都加了索引，则加的是行锁；否则加的是表锁。下面我们从几个方面对比下行锁和表锁表1
| 对比方向 | 行锁 | 表锁 |
|---|---|---|
| 锁定粒度 | 小 | 大 |
| 是否会发生死锁 | 会 | 不会 |
| 锁冲突概率 | 小 | 大 |
| 并发数 | 多 | 少 |
| 开销 | 小 | 大 |
- 读锁（共享锁）：允许其他线程上读锁，但是不允许上写锁; SELECT * FROM t_cms_promotion t WHERE t.pro_id = ? LOCK IN SHARE MODE
- 写锁（排他锁）：不允许其他线程上任何锁。 SELECT * FROM t_cms_promotion t WHERE t.pro_id = ? FOR UPDATE
注：如果让以上SQL语句上行锁，查询条件pro_id需要建立索引
