请问索引问题

Question

我想知道通过库或者日志等如何能全局查看某个库中的某个表索引有问题，
以及某个库中某个表的语句会出现死锁呢？
我想日常监测，如何能全局的查出来呢，谢谢

Answer 1

顺序是A select * from user where id in lock share mode（共享锁)
B update user set name='55' where id=1（此时锁住等待A释放锁)
A update user set name='66' where id=1（这个时候会出现死锁)
B 由于A死锁退出B提交顺序是A select * from user where id=1 for update(排他锁）
B update user set name='55' where id=1（此时锁住等待A释放锁)
A update user set name='66' where id=1
A COMMIT成功释放锁；
B 此时可以提交书中解释是A的共享锁B无法获取所以放入队列，A此时update与队列的B的update冲突造成死锁，
为什么呢？为什么如果A是排他锁就不会出现冲突死锁的现象？帮我解决这个问题吧

Answer 2

1.如果A先得到了共享锁，接着b试图获取排它锁，只能等待A释放共享锁，可是按你的时序，A接着要更新，必须获取排它锁，它必须等到B释放排它锁，这样，两者形成相互等待，造成死锁2.如果A先得到了排它锁，接着b试图获取排它锁，只能等待A释放排它锁，接着A进行更新操作，因为已经有了排它锁，顺利更新，然后释放，然后b得以获取排它锁，更新完成。所以不会有冲突。

Answer 3

因为已经有了排它锁，顺利更新
我不明白的是共享锁本身就是防止B更新，为什么就不能顺利的更新
同时共享锁时为什么A需要等待B释放排他锁，而排他锁时A就不需要等待B了，B同样是申请了排他锁的
，按照时序为什么一个是会发生相互等待，而一个是不需要呢？
共享锁本身也是防止你更新的啊，谢谢啦哎

Answer 4

>>: 因为A虽得到了共享锁，但是接着B马上又申请了排它锁，然后A再想更新，必须要获得写锁（或排它锁），它必须等到B的请求处理完之后才能获得写锁再更新数据。原理就是这样，这里有个时序问题。另外一个不需要等待，是因为它本身就已经得到了排它锁。但是实际上，这个还是跟数据库的具体实现有关的。我相信sqlite 就不是这样的机理。
BTW, 你这个是什么数据库？