大家好，我在bing。对于那些像我一样发展经验的朋友，当我提到更新时，这不仅仅是更新的查询声明。在互联网上，一种陈述也很重要。
图1
这种陈述不行。由于今天的在线错误，我重新结束了我熟悉和陌生的朋友。
（本文以MySQL为例）
特定的理论知识参考：数据库的交易级别（交易的隔离水平）
我们知道，基于事务的基本要素和将要出现的并发问题，ISQL的交易隔离级别被引入：
你为什么要拉这个？因为这是造成此问题的原因。
让我们先看一下此代码
图2
这是我从Git提交的图片。您可以看到第二行和第三行之间的区别。这是第二行，是该交易交易的显式支出。这对程序错误的预示了。根据在线和以前，这是一个线路锁，可以确保可以重复读取问题。然后与MySQL当前的默认交易隔离级别相同。为什么需要锁定概念？
错误是如何发生的？
重新出现：
一个简单的发布任务逻辑，该任务是同时发布的，以创建任务和订单，然后为任务付费。这里有交易的嵌套逻辑。也就是说，发布任务和创建顺序是由同学开发的，付款部件是由特殊同学开发的。付费的同学提供了向发布该任务的学生提供接口电话。通信级别是所需的类型（也就是说，如果您添加问题，如果您有交易，如果您不添加交易），但是同事制定任务的人已将接口的接口的传输级别更改为必需的_newthere是悬挂它的原始事务。在拨打电话付款之前，学生执行了ID生成规则的ID（用于更新语句），并且在付款期间报告了错误，因为这次付款时，该陈述最初成立的交易不是已提交，但被悬挂，这导致了交易更新超时，然后抛出了“超过锁定时间；尝试重新启动交易”。
图3
见到我的精神感觉并不是那么简单地看到这个问题。因为我的认知，更新是线路锁。生成的ID和资本详细信息的生成详细信息中的任务ID的ID是两个记录。为什么会影响？LOC更新锁定仪？
然后我在选择陈述上进行了解释，以证明我的想法。
图4
为什么扫描7行？手表中有7个记录。为什么不通过ID查询索引？
今天！
图5
id不是主要钥匙！当然，我不会去索引！那一定是扫描！
问题已在这里找到。
测试SQL：
文章创建的灵感来自：1024 Innovation Lab Wang Kai
原始：https：//juejin.cn/post/7101108317879009317