标签：io 使用 strong for 数据 sp 问题 on c
MySQL 不同引擎的锁机制：
MyISAM和MEMORY采用表级锁（table-level locking）
BDB采用页面锁（page-leve locking）或表级锁，默认为页面锁
InnoDB支持行级锁（row-level locking）和表级锁，默认为行级锁
锁特点：
表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生冲突的概率最高，并发度最低
行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高
页面锁：开销和加锁时间介于表锁和行锁之间；会出现死锁；锁定粒度介于表锁和行锁之间，并发度一般
InnoDB存储引擎的锁
InnoDB存储引擎实现了如下两种锁
1、共享锁（S Lock），允许事务读一行数据
2、排他锁（X Lock)，允许事务更新或者删除一行数据
一致性的非锁定读（类似于Oracle的 CR块）
一致性的非锁定行读（consistent nonlocking read）是指InnoDB存储引擎通过行多版本控制（multi versioning）的方式来读取当前执行时间数据库中行的数据。如果读取的行正在执行DELETE、UPDATE操作，这是读取操作不会因此而会等待行上锁的释放，相反，InnoDB会去读取行的一个快照数据。
之所以称其为非锁定读，因为不需要等待访问的行上X锁的释放。快照数据是指改行之前版本的数据，该实现是通过undo段来实现的。但是在不同事务隔离级别下，读取的方式不同，并不是每个事务隔离级别下读取的都是一致性读。
死锁的相关问题：
1：死锁发生的条件：
互斥条件：一个资源每次只能被一个进程使用；请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放；不剥夺条件:进程已获得的资源，在末使用完之前，不能强行剥夺；循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。
2：死锁检测：
Innodb检测死锁有两种情况，一种是满足循环等待条件，还有另一种策略：锁结构超过mysql配置中设置的最大数量或锁的遍历深度超过设置的最大深度时，innodb也会判断为死锁（这是提高性能方面的考虑，避免事务一次占用太多的资源）。
因循环等待条件而产生的死锁只有可能是四种形式：两张表两行记录交叉申请互斥锁、同一张表则存在主键索引锁冲突、主键索引锁与非聚簇索引锁冲突、锁升级导致的锁等待队列阻塞。
3：死锁避免：
1.如果使用insert…select语句备份表格且数据量较大，在单独的时间点操作，避免与其他sql语句争夺资源，或使用select into outfile加上load data infile代替 insert…select，这样不仅快，而且不会要求锁定
2. 一个锁定记录集的事务，其操作结果集应尽量简短，以免一次占用太多资源，与其他事务处理的记录冲突。
3.更新或者删除表格数据，sql语句的where条件都是主键或都是索引，避免两种情况交叉，造成死锁。对于where子句较复杂的情况，将其单独通过sql得到后，再在更新语句中使用。
4. sql语句的嵌套表格不要太多，能拆分就拆分，避免占有资源同时等待资源，导致与其他事务冲突。
5. 对定点运行脚本的情况，避免在同一时间点运行多个对同一表进行读写的脚本，特别注意加锁且操作数据量比较大的语句。
6.应用程序中增加对死锁的判断，如果事务意外结束，重新运行该事务，减少对功能的影响。
4：死锁解决：
1.先执行show processlist找到死锁线程号.然后Kill pid
2.Show innodb status检查引擎状态 ,可以看到哪些语句产生死锁
3.查看information_schema架构下的innodb_locks、innodb_trx、innodb_lock_waits等表
标签：io 使用 strong for 数据 sp 问题 on c
原文地址：http://www.cnblogs.com/xiaoit/p/3982839.html
