MySQL锁的优化

获取锁等待情况

可以通过检查table_locks_waited和table_locks_immediate状态变量来分析系统上的表锁定争夺：

可以通过检查Innodb_row_lock状态变量来分析系统上的行锁争夺情况：

另外，针对InnoDB类型的表，如果需要查看当前的锁等待状况，可以这是InnoDB Monitors，然后通过show innodb status查看，设置的方式是：

监视器可以通过发出下列语句来被停止：

设置监视器后，在show innodb status的显示内容中，会有详细的当前锁等待的信息，包括表名、锁类型、锁定记录的情况等，便于进步的分析和问题的确定。打开监视器后，默认情况下每15秒会向日志中记录监控的内容，如果长时间打开会导致.err文件变得十分巨大，所以我们在确认问题原因后，要记得删除监控表以关闭监视器。或者通过使用--console选项来启动服务器关闭写日志文件。

什么情况下使用表锁

表级锁在下列几种情况下比行级锁更优越：

1、很多操作都是读表

2、在严格条件的索引上读取和更新，当更新或者删除可以用单独的索引来读取得到时

3、UPDATE table_name SET column=value WHERE unique_key_col=key_value;

4、DELETE FROM table_name WHERE unique_key_col=key_value

5、SELECT和INSERT语句并发的执行，但是只有很少的UPDATE和DELETE语句

6、很多的扫描表和对全表的GROUP BY操作，但是没有任何写表

什么情况下使用行锁

行级锁的有点：

1）当在许多线程中访问不同的行时只存在少量锁定冲突

2）回滚只有少量的更改

3）可以长时间锁定单一的行

行级锁的缺点：

1）比页级或表级锁占用更多的内存

2）当在表的大部分中使用时，比页级或表级锁定速度慢，因为你必须获取更多的锁

3）如果你在大部分数据上经常进行GROUP BY操作或者必须经常扫描整个表，比其他锁定明显慢很多

4）用高级别锁定，通过支持不同的类型锁定，你也可以很容易地调节应用程序，因为其锁成本小于行级锁

Insert...Select...带来的问题

当使用insert...select...进行记录的插入时，如果select的表是innodb类型的，不论insert的表是什么类型，都会对select的表的记录进行行锁定。

对于那些从Oracle迁移过来的应用，需要特别的注意，因为Oracle并不存在类似的问题，所以在Oracle的应用中Insert...Select...操作非常的常见。例如：有时候需要对比较多的记录进行统计分析，然后将统计的中间结果插入到另外一个表，这样的操作因为进行的非常少，所以可能并没有设置相应的索引。如果迁移到MySQL数据库后不进行响应的调整，那么在进行这个操作期间，对需要Select的表实际上是进行全表扫描导致的所有记录的锁定，将会对应用的其他操作造成非常严重的影响。

究其主要原因，是因为MySQL在实现复制的机制时和Oracle是不同的，如果不进行Select表的锁定。则可能造成从数据库在恢复器件插入结果集的不同，造成主从数据的不一致。如果不采用主从复制，关闭binlog并不能避免对Select记录的锁定，某些文档中提到可以通过设置innodb_locks_unsafe_binlog来避免这个现象，当这个参数设置为true的时候，将不会对Select的结果集加锁，但是这样的设置可能带来非常严重的隐患。如果使用这个binlog进行从数据库的恢复，或者进行主数据库的灾难恢复，都将可能和主数据库的执行效果不同。

因此，并不推荐通过这个参数的设置来避免Insert...Select..导致的锁，如果需要进行可能会扫描大量数据的Insert...Select...操作，推荐使用Select...Into outfile 和 load data infile 的组合来实现，这样是不会对记录进行锁定的。

Next-key锁对并发插入的影响

在行级锁定中，InnoDB使用一个名为next-key locking的算法。InnoDB以这样的一种方式执行行级锁定：当它搜索或扫描的索引之时，它对遇到的索引记录设置共享或独占锁定，因此，行级锁定事实上是索引记录锁定

InnoDB对索引记录设置的锁定也映像索引记录之前的“间隙”。如果一个用户对一个说阴山的记录R有共享或独占的锁定，另一个用户不能紧接在R之前以索引的顺序插入一个新的索引记录。这个间隙的锁定被执行来防止所谓的“幽灵问题”。

可以用next-key锁定在你的应用程序上实现一个唯一性检查：如果你以共享模式读数据，并且没有看到你将要插入的行的重复，则你可以安全地插入你的行，并且知道在读过程中对你的行的继承者设置的next-key锁定与此同时阻止任何人对你的行插入一个重复、因此，next-key锁定允许你锁住在你的表中并不存在的一些东西。

隔离级别对并发插入的影响

REPETABLE READ是InnoDB的默认隔离级别。带唯一搜索条件使用唯一索引的SELECT...FOR UPDATE, SELECT ...LOCK IN SHARE MODE, UPDATE和DELETE语句只锁定找到的索引记录，而不锁定记录前的间隙。用其他搜索条件，这些操作采用next-key锁定，用next-key锁定或者间隙锁定锁住搜索的索引范围，并且阻止其他用户的新插入。

在持续读中，有一个与READ COMMITED隔离级别重要的差别：在这个级别，在同一事务内所有持续读读取由第一次读所确定的同一快照。这个惯例意味着如果你在同一事务内发出无格式的SELECT语句，这些SELECT语句对相互之间也是持续的。

READ COMMITED隔离级别是一个有些像Oracle的隔离级别。所有SELECT ... FOR UPDATE和SELECT ... LOCK IN SHARED MOD语句仅仅锁定索引记录，而不锁定记录前的间隙，因而允许随意挨着已锁定的记录插入新记录。UPDATE和DELETE语句使用一个带唯一搜索条件的唯一的索引仅锁定找到的索引记录，而不包括记录钱的间隙。

在范围类型UPDATE和DELETE语句，InnoDB必须对范围覆盖的间隙设置next-key锁定或间隙锁定以及其他用户做的块插入。这是很必要的，因为要让MySQL复制和恢复起作用，“幽灵行”必须被阻止掉。

如果应用是基于Oracle的应用迁移到MySQL数据库的，那么建议使用该隔离级别提供的数据库服务，因为该隔离级别是最接近Oracle的默认隔离级别的，迁移可能遇到的锁问题最小。

如何减少锁冲突

对MyISAM类型的表：

1）MyISAM类型的表可以考虑铜鼓改成InnoDB类型的表来减少锁冲突

2）根据应用情况，尝试横向拆分层多个表或者改成MyISAM分区对减少锁冲突也有一定的帮助

对InnoDB类型的表：

1) 首先要确认，在对表获取行锁的时候，要尽量的使用索引检索纪录，如果没有使用索引访问，那么即便你只是要更新其中的一行纪录，也是全表锁定的。要确保sql是使用索引来访问纪录的，必要的时候，请使用explain检查sql的执行计划，判断是否按照预期使用了索引。

2) 由于mysql的行锁是针对索引加的锁，不是针对纪录加的锁，所以虽然是访问不同行的纪录，但是如果是相同的索引键，是会被加锁的。应用设计的时候也要注意，这里和Oracle有比较大的不同。

3) 当表有多个索引的时候，不同的事务可以使用不同的索引锁定不同的行，当表有主键或者唯一索引的时候，不是必须使用主键或者唯一索引锁定纪录，其他普通索引同样可以用来检索纪录，并只锁定符合条件的行。

4) 用SHOW INNODB STATUS来确定最后一个死锁的原因。查询的结果中，包括死锁的事务的详细信息，包括执行的SQL语句的内容，每个线程已经获得了什么锁，在等待什么锁，以及最后是哪个线程被回滚。详细的分析死锁产生的原因，可以通过改进程序有效的避免死锁的产生。

5) 如果应用并不介意死锁的出现，那么可以在应用中对发现的死锁进行处理。

6) 确定更合理的事务大小，小事务更少地倾向于冲突。

7) 如果你正使用锁定读，（SELECT ... FOR UPDATE或 ... LOCK IN SHARE MODE），试着用更低的隔离级别，比如READ COMMITTED。

8) 以固定的顺序访问你的表和行。则事务形成良好定义的查询并且没有死锁。