这是一个创建于 339 天前的主题，其中的信息可能已经有所发展或是发生改变。
mysql5.7 插入、更新数据时报错：Lock wait timeout exceeded; try restarting transaction 。定时同步插入、更新到其它数据库时会上行锁。历史遗留问题主键 ID 为 uuid 。目前看超时时间是默认 50s ，临时改为 100s 了。 想不明白都是上的行锁，为啥插入不进去，不知什么原因变成表锁了。目前考虑增加硬件配置会不会好些，还是要将数据库连接池的最大数量调低。
第 1 条附言 · 339 天前
抱歉，没看仔细，ID 不是主键是唯一索引，还有订单流水号的唯一索引。
第 2 条附言 · 331 天前
经过几天超时频发，通过查看日志发现有共享锁锁的不是唯一索引，会有间隙锁，经分析该锁的实际意义不大，已经删除。
后间隔一天后，线上又频发超时，通过 SHOW FULL PROCESSLIST 发现某个 update 语句执行时间太长，导致很多 update 和 insert 等待，kill 该语句后恢复。经查阅资料和自己实践发现该 update 语句中的条件有子查询，导致锁住更新表，后该 update 语句改为 inner join 更新。
后间隔一天后，线上又频发超时，通过 SHOW FULL PROCESSLIST 发现某个 update 语句执行时间太长，导致很多 update 和 insert 等待，kill 该语句后恢复。经查阅资料和自己实践发现该 update 语句中的条件有子查询，导致锁住更新表，后该 update 语句改为 inner join 更新。
 |
1
fmumu 339 天前
多线程插入吗? 改单线程排队去插入
|
 |
2
Pythoner666666 339 天前
看下是不是事务太大了，如果是的话拆一下
|
 |
3
7911364440 339 天前
更新数据走索引吗，不走的话就是表锁
|
 |
4
encro 339 天前
需要看具体的场景，
1 ，show full processlist 查看可能锁表的进程； 2 ，是否异常导致事务未提交或者回滚； 3 ，是否修改时需要索引重新排序； |
 |
5
siweipancc 339 天前 via iPhone
大事务就换成 redis 锁，不然就乐观锁，永远不要锁行，用不好就升级成表锁
|
 |
6
themostlazyman OP @7911364440 走主键或者唯一索引。
|
|
7
themostlazyman OP @encro 确实有修改时索引重排。有两个字段。这样会导致表锁吗？
|
|
8
encro 339 天前  1
show full processlist 看下是谁在执行，谁在 wait ，状态是什么，那个卡住了，不一定是你说的语句卡住了，可能是一个 count 或者 order by 让数据库卡住了都不一定。
|
|
9
encro 339 天前
而且可能往往是事务没有正常释放容易导致卡住，这种情况要远超其他情况。
|
Select Language