帮我分析一个死锁的情况分析
根据代码数据库死锁问题 (java+mysql)
PersisterDAO: stange error:com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction
com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 在日志我找到原因在这个时间点：
机器a b 都在向服务器的数据库的同1个表update 和insert 操作。
a 的语句
update bo set istrue='1', Type='n' whereid in (-1,145195331580,115495331579,11495293590,1195293618,1195293616,1
1495293613,1195293583,1195293596,1195293611,1195293614,1195293601,1195293606,1195293597,1195293612,1195293591,11495293615,1195293604,1195293608,1195293617,1195293584,1
19545293603,1195293594,1195293580,1195293599,1195127791,1195127792,1195127790,1195127794,1195127793,1195293983,119545293982,1195161938,1195115124,1195115125,1195115123,1
19511514518,1195133633,1195252452,119525542446,1195056765,1195056761,1195311014,1195311012,1195311013,1195295175,11952951572,1195126185,1195126183,1195126182,1195125233,1
19512522458,51195125220,1195226874,119455253267,1195253268,1195253974,1195283157,1195283156,1195283158,1194709909,119470954907,1194709885,119470945898,1194709884,1194709901,1。）
这个语句是update 开始时间是2009-07-24 00：00：00。 执行时间是3秒b的语句
insert into bo values(1,1,1,,1,11,),(2,2,,,22,) ,(3,,324,3,33,4),(4,45,4,5,4,5)......
是一个批量的sql大语句。
这个语句
开始时间是2009-07-24 00：00：02。 执行时间是3秒
我认为会发生死锁，但是有的开发人员说不会我的看法是a 开始时间是2009-07-24 00：00：00。 执行时间是3秒，说明b如果在
00：00：03 那么大家都是ok的 ，但是b在2009-07-24 00：00：02开始发生死锁。
a是更新锁 ，b是写锁。可否根据三级封锁协议？？（还是分析不下去）
另外找了些理由：
1当在同一个表上同时有插入和删除操作时，INSERT DELAYED 可能会很有用；
2 只要对同一个表没有大量的更新和查询操作混在一起，目前的用户并不是问题。问题还是在这里现在唯一反驳的观点，a是一个大sql 他执行的时候会他数据产生行级锁，
b也是一个大sql，他是否会避开a的更细不矛盾的插入数据到bo表 ？？？
根据代码数据库死锁问题 (java+mysql)
PersisterDAO: stange error:com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction
com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 在日志我找到原因在这个时间点：
机器a b 都在向服务器的数据库的同1个表update 和insert 操作。
a 的语句
update bo set istrue='1', Type='n' whereid in (-1,145195331580,115495331579,11495293590,1195293618,1195293616,1
1495293613,1195293583,1195293596,1195293611,1195293614,1195293601,1195293606,1195293597,1195293612,1195293591,11495293615,1195293604,1195293608,1195293617,1195293584,1
19545293603,1195293594,1195293580,1195293599,1195127791,1195127792,1195127790,1195127794,1195127793,1195293983,119545293982,1195161938,1195115124,1195115125,1195115123,1
19511514518,1195133633,1195252452,119525542446,1195056765,1195056761,1195311014,1195311012,1195311013,1195295175,11952951572,1195126185,1195126183,1195126182,1195125233,1
19512522458,51195125220,1195226874,119455253267,1195253268,1195253974,1195283157,1195283156,1195283158,1194709909,119470954907,1194709885,119470945898,1194709884,1194709901,1。）
这个语句是update 开始时间是2009-07-24 00：00：00。 执行时间是3秒b的语句
insert into bo values(1,1,1,,1,11,),(2,2,,,22,) ,(3,,324,3,33,4),(4,45,4,5,4,5)......
是一个批量的sql大语句。
这个语句
开始时间是2009-07-24 00：00：02。 执行时间是3秒
我认为会发生死锁，但是有的开发人员说不会我的看法是a 开始时间是2009-07-24 00：00：00。 执行时间是3秒，说明b如果在
00：00：03 那么大家都是ok的 ，但是b在2009-07-24 00：00：02开始发生死锁。
a是更新锁 ，b是写锁。可否根据三级封锁协议？？（还是分析不下去）
另外找了些理由：
1当在同一个表上同时有插入和删除操作时，INSERT DELAYED 可能会很有用；
2 只要对同一个表没有大量的更新和查询操作混在一起，目前的用户并不是问题。问题还是在这里现在唯一反驳的观点，a是一个大sql 他执行的时候会他数据产生行级锁，
b也是一个大sql，他是否会避开a的更细不矛盾的插入数据到bo表 ？？？
发现2个影响不大，无非是等一会。 （update的 同时，可以insert新的记录）
大概5分钟过去，lock自动消失。
奇怪的是， 服务器的慢查询日志没有记载这几个update 或者insert语句 。
现在想如何记载在线系统发生死锁定语句？