MongoDB的不足之处仍有很多，而其中让我最感到痛心的就是MongoDB的全局锁！
怎么样的全局锁呢？相对于MySQL数据库来做个对比！MySQL数据库其中的MyIsam存储引擎使用的表锁，写会锁定整个表；而锁粒度相对较小的是Innodb，采用的是行锁！这样对比起来，MyISAM优势下降很多！而MongoDB的全局锁，粒度及其大，大得不敢让人相信，它不是MyISAM的表锁，甚至还超越了库锁，它竟然是整个服务上的锁。
也就是说，MongoDB一个写操作会锁定整个server级别的其他读写操作！我自己做个一个测试，在一个大约有3000w行的collection中添加一个索引，坑爹的事情发生了！这个添加索引的操作，锁定这整个服务，我在另外一个连接上，show dbs这个命令都被阻塞着，直到添加索引的操作完成！
但是MongoDB可以高并发读！
据说MongoDB已经在研发基于collection的锁粒度，也就是关系型数据库中的表锁粒度！
关于MongoDB的全局锁
对MongoDB有所了解的人都知道，MongoDB有一个让人头疼的全局锁（读写锁，允许并发读，而写会阻塞所有的读写），要命的是这个锁不是表级的，不是库级的，而是整个Server级别的，这让人听起来是不是非常的蛋疼。
在2.0版本以前，这一问题一直没有得到解决，于是有人提出，在可预见某个update操作的记录可能在磁盘上时，为了减少写锁占用的时间，可以采 用先读后写的方式，通过先读一次，将要操作的记录加载到内存中，再进行内存中的update，这样写锁就不包括将数据从磁盘加载到内存的时间了。
在可预见数据冷热的情况下，这种操作能够有一定的效果，但是很明显，这种变态的方法不应该是一个终极解决方案。
值得庆幸的是，在2.0版本中，MongoDB宣称有很大程度的并发性能提升，而这一提升的基础正是解决了这个全局锁的问题。
解决的方法并不是通过减少锁粒度来解决，虽然collection级别的锁机制也正在开发中。（SERVER-1240）
解决方法是通过对一些可能造成长时间锁占用的操作进行锁抑制。比如和我们上面的方法类似，在进行update操作时，如果发现需要更新的记录在磁盘上，那么这个锁就不会一直占用，而是等到将数据从磁盘加载到内存后再添加写锁进行update。
而同理，对于其它一些可能耗时比较长的操作也可以采用类似的方法，通过将长时间占用的全局锁拆分成多个细粒度的小锁来使需要获取锁来进行的操作能够交错的执行，从而避免一夫当关万夫莫开的情况，主要包括下面一些操作：
查询操作
批量更新操作
批量删除操作
批量insert写入操作
如果你还在使用2.0以前的版本，并且在并发性能上出现问题，可以考虑在2.0.x版本上进行一些性能测试并对你的MongoDB进行升级。
对MongoDB有所了解的人都知道，MongoDB有一个让人头疼的全局锁（读写锁，允许并发读，而写会阻塞所有的读写），要命的是这个锁不是表级的，不是库级的，而是整个Server级别的，这让人听起来是不是非常的蛋疼。
在2.0版本以前，这一问题一直没有得到解决，于是有人提出，在可预见某个update操作的记录可能在磁盘上时，为了减少写锁占用的时间，可以采 用先读后写的方式，通过先读一次，将要操作的记录加载到内存中，再进行内存中的update，这样写锁就不包括将数据从磁盘加载到内存的时间了。
在可预见数据冷热的情况下，这种操作能够有一定的效果，但是很明显，这种变态的方法不应该是一个终极解决方案。
值得庆幸的是，在2.0版本中，MongoDB宣称有很大程度的并发性能提升，而这一提升的基础正是解决了这个全局锁的问题。
解决的方法并不是通过减少锁粒度来解决，虽然collection级别的锁机制也正在开发中。（SERVER-1240）
解决方法是通过对一些可能造成长时间锁占用的操作进行锁抑制。比如和我们上面的方法类似，在进行update操作时，如果发现需要更新的记录在磁盘上，那么这个锁就不会一直占用，而是等到将数据从磁盘加载到内存后再添加写锁进行update。
而同理，对于其它一些可能耗时比较长的操作也可以采用类似的方法，通过将长时间占用的全局锁拆分成多个细粒度的小锁来使需要获取锁来进行的操作能够交错的执行，从而避免一夫当关万夫莫开的情况，主要包括下面一些操作：
查询操作
批量更新操作
批量删除操作
批量insert写入操作
如果你还在使用2.0以前的版本，并且在并发性能上出现问题，可以考虑在2.0.x版本上进行一些性能测试并对你的MongoDB进行升级。