数据库锁

悲观锁(Pessimistic Lock), 顾名思义，就是 对数据的一致性 很悲观，每次去拿数据 (无论是读数据还是写数据) 的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型 数据库 里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。 乐观锁(Optimistic Lock), 顾名思义，就是 对数据的一致性 很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁 适用于多读 的应用类型，这样可以提高吞吐量，像数据库如果提供类似于write_condition机制的其实都是提供的乐观锁。 两种锁各有优缺点，不可认为一种好于另一种，像乐观锁适用于 写比较少 ,读比较多 的情况下，即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。但如果经常产生冲突，上层应用会不断的进行retry，这样反倒是降低了性能，所以这种情况下用悲观锁就比较合适 ,即 更新数据 比较频繁的应该用悲观所. 来源： oschina 链接： https://my.oschina.net/u/2459446/blog/703995

最近忽然发现项目提交的时候一直在提交状态，不能提交成功，客户反馈提交了4个多小时还在提交中，应用也没发现什么明显错误，前台显示如下（IE下才会有这种提示，其他的浏览器没错误）： 刚发现该问题的时候，网络查了一遍基本没发现靠谱的，倒是看到一个有意思的 按照这位大佬的方法修改了，依旧还是无法提交，请求一直在挂起状态，程序中的各种页面跳转没有任何问题，就是在提交的时候无法提交成功，找了一两天，感觉不是程序的问题，将目光转向数据库。 发现数据库一堆锁表，问题终于确定是数据库锁表导致提交不成功的，使用工具查询 各种锁，看sql是一条查询语句很久没出结果，而这个查询语句锁了表。 在印象中锁表一直都是插入和更新才锁表，而且还是行锁，查询也会锁表，赶紧补习一下，数据库的锁有很多种，但大致可以分为S锁（共享锁）以及U锁（排他锁），查询的时候会加上S锁，S锁对其他的查询无影响，但是插入和更新则会因为这个锁导致无法插入和更新，而这个sql查询统计的时候耗时非常久，故而导致了整个应用出现问题。根据工具排查出某个古老的应用在进行这个查询，临时先将该应用关闭，恢复正常的业务。 但问题还是要解决，总不能一直关闭那个老应用吧，暂时给出的方案： 1，对表增加索引，让查询更快点 2，对查询语句进行修改，加上 WITH(NOLOCK) 来去掉这个共享锁，当然这也会产生其他问题，比如脏读问题，具体还是要看各自的业务