Mysql锁机制

mysql锁机制
mysql中对表级的存储引擎来说是释放死锁的，避免死锁可以这样做到:在任何查询之前先请求锁，并且按照请求的顺序锁表。
Mysql中用于write(写)的表锁的实现机制如下：
如果表没有加锁，那么就加一个写锁。否则的话，将请求放到写锁队列中。
mysql中用于read(读)的表锁的实现机制如下：
如果表没有加锁，那么就加一个读锁。否则的话，将请求放到读锁队列中。
比方说一开始没有锁，我读数据，这时就加一个读锁，这时如果来个写操作，那么就把写操作请求放到写锁队列中。
比方说一开始没有锁，我写操作，这时就加一个写锁，这时如果来个读操作，那么就把读操作请求放到读锁队列中。
当锁释放后，写锁队列中的线程可以用这个锁资源，然后才轮到读锁队列中的线程。
这就是说，如果表里有很多更新操作的话，那么select必须等到所有的更新都完成了之后才能开始。
让select速度尽量快，这可能需要创建一些摘要表。
以下是mysql锁的一些建议：
只要对同一个表没有大量的更新和查询操作混在一起，目前的用户并不是问题。
执行LOCK TABLES来提高速度(很多更新操作放在一个锁中 比没有锁的 很多更新快多了),将数据拆分开到多个表中可能也有帮助。
当mysql碰到由于锁表引起的速度问题时，将表类型转换成InnoDB或BDB可能有助于提高性能。
事务处理和并发性
1.全部的表类型都可以使用锁，但是只有InnoDB和BDB才有内置的事务功能
2.使用begin开始事务，使用commit结束事务，中间可以使用rollback回滚事务。
3.在默认情况下，InnoDB表支持一致读。
SQL标准中定义了4个隔离级别：read uncommited,read commited, repeatable read, serializable.
read uncommited即脏读，一个事务修改了一行，另一个事务也可以读到该行。
如果第一个事务执行了回滚，那么第二个事务读取的就是从来没有正式出现过的值。
read commited即一致读，试图通过只  读取提交的值的方式来解决脏读的问题，但是这又引起了不可重复读取的问题。
一个事务执行一个查询，读取了大量的数据行，在它结束读取之前，另一个事务可能已经完成了对数据行的更改。当第一个事务
再次执行同一个查询，服务器就会返回不同的结果。
repeatable read即可重复读，在一个事务对数据行执行读取或写入操作时锁定了这些数据行。但是这种方式又引发了幻想读的
问题。 因为只能锁定 读取或写入的行，不能阻止另一个事务插入数据，后期执行同样的查询会产生更多的结果。
serializ