mysql update的底层逻辑是什么？update大量行性能如何？在事务里update大批量数据会不会容易出现死锁？

Question

目前遇到的一个场景，需要在事务的最后对一些数据的状态进行变更。
这些需要update的数据可能是1000条，也可能是1万条。
因为这张表的读写频率很高，如果在事务里执行一个update table set status = 1 where x（数据量1000-10000），那么会有几率出现死锁吗？
所以这就引出了一个问题，update的底层原理是啥？执行一句这样的update性能如何？

Answer 1

看看官方文档：https://dev.mysql.com/doc/refman/8.0/en/update.html

Answer 2

mysql执行update是走行锁还是表锁，要看用的引擎，高频读写的表，选择innoDB，支持行锁，这样update只会锁where条件范围内的。
关于数据库的死锁，是因为两个事务竞争锁造成的，持有对方的锁，又互相申请，所以单个场景的单个事务，没发判断是否会死锁，要看有没有其他事务在持有锁的时候，又需要拿这次update相关的行锁
至于update底层原理，你想了解啥，大致的实现就是锁数据，改数据，释放锁，之前mysql的版本，有实验过的，如果更新的列非索引，同时更新后的数据和现有数据的字节长度一样，数据在存储中并不会发生位移，如果是其他情况，数据会发生位移，但这些都属于mysql本身的实现机制，版本变化，可能跟着就变化了
另外，update可以走batch，减少提交次数，提升速度，坏处就是其中一条失败了，整体回滚，不过既然是在一个应用事务，那整体回滚应该是可以接受的。至于性能，1000-10000的数据量，这需要看软硬件配置，看具体的sql，看索引更新，很多的因素，可以explain看一下，根据具体的情况来调优