序言
如何保证数据并发访问的一致性和有效性，是所有数据库必须解决的一个问题。另外，锁冲突也是影响数据库并发性能的一个重要因素，应用程序在选择锁类型时，需要根据实际运行的需要，选择最佳的锁类型
锁类型
Myisam和Memory引擎使用的是表级锁
innodb引擎使用的是行级锁
BDB引擎使用的是页级索
锁解释
行级锁：他直接锁住的是一条记录，开销大，加速慢，发生锁冲突的概率较低，并发度很高。
页级索：它锁住的是一个页面，在innodb中一个页面为16kb，它的开销介于表级锁和行级锁中间，也可能会出现死锁，锁定粒度也介于表级锁和行级锁中间，并发度也介于表级锁和行级锁中间
表级索：他直接锁住的是一个表，开销小，加锁快，不会出现死锁的情况，锁定粒度大，发生锁冲突的概率更高，并发度最低
innodb行级锁
innodb有俩种类型的行级锁，俩种内部使用的意向锁。
共享锁(S):允许一个事务读一行数据时，阻止其他的事务读取相同数据的排他锁。
排他锁(X):允许获得排他锁的事务更新数据，阻止其他事务取得相同数据的共享锁和排他锁。他锁
意向共享锁(IS):事务打算给数据行加行共享锁。事务在给一个数据行加共享锁前必须先取得该表的IS锁。
意向排他锁(IX):事务打算给数据行加行排他锁。事务在给一个数据行加排他锁前必须先取得该表的IX锁。
悲观锁(抽象，不真实存在的锁)
乐观锁(抽象，不真实存在的锁)
共享锁，只可以读不可以写
排它锁，不可以读也不可以写
4种锁的共存逻辑关系表
共享锁的使用
共享锁跟共享锁
死锁情况
对于锁的建议
收集死锁信息： 利用命令 SHOW ENGINE INNODB STATUS查看死锁原因。 调试阶段开启 innodb_print_all_deadlocks，收集所有死锁日志。 减少死锁： 使用事务，不使用 lock tables 。 保证没有长事务。 操作完之后立即提交事务，特别是在交互式命令行中。 如果在用 (SELECT ... FOR UPDATE or SELECT ... LOCK IN SHARE MODE)，尝试降低隔离级别。 修改多个表或者多个行的时候，将修改的顺序保持一致。 创建索引，可以使创建的锁更少。 最好不要用 (SELECT ... FOR UPDATE or SELECT ... LOCK IN SHARE MODE)。 如果上述都无法解决问题，那么尝试使用 lock tables t1, t2, t3 锁多张表
