一类锁表问题的分析

今天在工作中，老大指出了表设计的问题。这张表的意图很简单，就是简单地记录内部员工的记录，当然还有一个总用户表，内部员工表中有一个字段“关联”总用户表（是手动维护这个内部员工表的，毕竟这个表中的数据量不大，才几百条记录，当时没有使用外键来关联）。

现在我们要做的事就是每次有一个特定的提前退出操作时，就会对内部员工记录中的一个字段进行更新操作。写的sql也很简单，大致如下：

UPDATE XXX SET XX=XX WHERE COLUMN=XX

现在的问题就是这个COLUMN字段，它没有索引，没有索引的话，当然会走全表扫描了，如果有其它的更新操作的话，这张表肯定会被锁表！

这是一类常见的锁表情况：在没有索引的情况下，多个更新操作会导致锁表情况的发生。

再来看一下InnoDB存储引擎下的锁机制。我们都知道Mysql支持行级锁和表级锁。行级锁的粒度会少很多，而表级锁相对简单很多了，但是它的性能不高。所以我们尽量让其走行级锁，这要可以提升整个系统的性能。

如上面所说，如果没有在where查询字段上建立索引的话，一个查询操作和更新操作并发执行，表的数据量很大，那么它就会被锁表。锁的原理在本质上是很简单的，如果读读并存，没有关联，可以一起执行，如果读写或者写写操作并存，那么这个就不允许一起执行了。

所以在这个版本中，我就按照老大的意思，在where后面查询的字段上建立了一个索引，不让它走全表扫描，避免全表扫描引起的锁表情况。

在Java中，有一个锁并发框架，它其实主要做了三件事情：
1. 计数（读写计数，有多少个线程在进行读写操作）;
2. 等待队列（如果当前的资源不允许进行操作，就是加锁了，那么该线程必须要等待了）；
3. 线程的阻塞和唤醒（使用底层操作系统的功能了）。

当然在Java中的锁，它提供了一系列的并发数据结构和不同锁机制的类，引入这个就是说明Mysql中锁的实现原理和机制。