mysql innodb死锁未锁定查询
我有一个奇怪的情况，两个相同的冲突查询（通过将不同的应用程序线程扔到同一记录中）。第二个将因僵局错误而失败。
查询是一个非常简单的更新表设置unIndexedColum = 1其中pk = x
检查应用程序和Inno状态，第一个（winning）查询具有“ S”锁，第二个A“ x”锁。 但是应用程序没有明确打开该锁。
是否可以通过应用程序或InnoDB自动制作锁？
该应用程序是带有Spring -JDBC的Java应用程序。
I have a strange situation, two identicaly conflicting queries (made by throw different application thread to the same record). The second one will fail with a DeadLock error.
The query is a very simple UPDATE table SET unindexedColum=1 WHERE pk=X
Checking the application and the inno status, the first (winning) query has a "S" lock, the second a "X" lock.
But application did not explicitly open that lock.
Is it possibile that a lock is made automatically by application or by InnoDB?
The application is a Java app with Spring - JDBC.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
mysql句柄锁行本人无需在应用程序上管理行的锁。只需管理应用程序的交易即可。
取决于您InnoDB配置
https://dev.mysql.com/ doc/refman/8.0/en/innodb-transaction-isolation-levels.html
mySQL将以不同的策略处理行上的锁，但默认可重复读取。
也许您需要选择要更新的行“选择更新” https://dev.mysql.com/doc/refman/8.0/en/innodb-locking-reads.html 在交易中进行清洁，并在应用程序中使用异常僵局。
Mysql handle lock row himself no need to manage lock at row on application. Just manage transaction on application.
Depending of you innodb configuration
https://dev.mysql.com/doc/refman/8.0/en/innodb-transaction-isolation-levels.html
MySQL will handle locks on rows with different strategy, but default REPEATABLE READ.
Maybe you need to select the row you want to update with "select for update" https://dev.mysql.com/doc/refman/8.0/en/innodb-locking-reads.html in a transaction to be clean, and use exception in application side if there is a deadlock.