安贞网站建设公司在线crm软件系统

当前位置： 首页 > news >正文

安贞网站建设公司,在线crm软件系统,官网seo关键词排名系统,网站设计公司南京一致性非锁定读 一致性的非锁定读#xff08;consistent nonlocking read#xff09;是指InnoDB存储引擎通过行多版本控制的方式读取当前执行时数据库中行的数据。 如果读取的行正在执行 行Delete或Update操作#xff0c;这时读取操作不会因此去等待行上锁的释放。相反consistent nonlocking read是指InnoDB存储引擎通过行多版本控制的方式读取当前执行时数据库中行的数据。 如果读取的行正在执行 行Delete或Update操作这时读取操作不会因此去等待行上锁的释放。相反InnoDB会去读行的一个快照数据。 之所以称为非锁定读因为不需要等地访问的行上X锁的释放。 快照数据是指该行的之前版本的数据通过undo段来实现的。而undo用来在事务中回滚数据因此快照数据本身时没有额外的开销。 此外读取快照数据是不需要上锁的因为没有事务需要对历史的数据进行修改操作。 因此非锁定读机制极大地提高了数据库的并发性。InnoDB存储引擎默认采取这种读取方式即读取不会占用和等待表上的锁。 但是在不同事务隔离级别下读取的方式不同并不是在每个事务隔离级别下都采用非锁定的一致性读。 此外即使都是使用非锁定读一致性读但是对于快照数据的定义也各不相同。 我们知道快照数据其实就是当前行数据之前的历史版本每行记录可能有多个版本一般称这种技术为行多版本技术。由此带来的并发控制称为多版本并发控制Multi Version Concurrency Control, MVCC。 隔离级别和非锁定的一致性读 在事务隔离级别READ COMMITED 和 REPEATABLE READInnoDB的默认事务隔离级别下InnoDB使用非锁定的一致性读。然而对于快照数据的定义却不同。 在READ COMMITTED事务隔离级别下对于快照数据非一致性读总是读取被锁定行的最新一份快照数据。 而在REPEATABLE READ级别下对于快照数据非一致性读总是读取事务开始时的行数据版本。 一致性锁定读 上面讲了在默认隔离级别REPEATABLE READ下InnoDB的SELECT操作使用一致性非锁定读。 但在某些情况下用户需要显式地对数据库读取操作进行加锁以保证逻辑的一致性。 而这要求数据库支持加锁语句即使是对于SELECT的只读操作也可以加锁。 InnoDB支持两种一致性的锁定读locking read操作 SELECT … FOR UPDATESELECT … LOCK IN SHARE MODE SELECT … FOR UPDATE 对读取的行记录加一个X锁其他事务不能对已锁定读行加上任何锁。 SELECT … LOCK IN SHARE MODE 对读取的行记录加一个S锁其他事务可以向北锁定的行加S锁但是如果该行已经加了X锁则会被阻塞。 对于一致性非锁定读即使读取的行已被执行了SELECT … FOR UPDATE也是可以进行读取的通过快照。 此外 SELECT … FOR UPDATE 和 SELECT … LOCK IN SHARE MODE必须在一个事务中当事务提交了锁也就释放了。 因此在使用上述两句SELECT锁定语句时务必加上BEGINSTART TRANSACTION或者SET AUTOCOMMIT0。 自增长与锁 自增在在数据库中时非常常见的一种属性也是很多开发人员首选的主键方式。 在InnoDB的内存结构中对每个含有自增长值的表都有一个自增长计数器auto-increment counter。 当对含有自增长的计数器的表进行插入操作时这个计数器会被初始化执行如下的语句来得到计数器的值 SELECT MAX(auto_inc_col) FROM t FOR UPDATE; 插入操作会依据这个自增长的计数器值加1赋予自增长列。这个实现方式被称做AUTO-INC Locking。 这种锁其实是采用一种特殊的表锁机制为了提高插入的性能锁不是在一个事务完成后才释放而是在完成对自增长值插入的SQL语句后立即释放。 虽然AUTO-INC Locking从一定程度上提高了并发插入的效率 但还是存在一些性能上的问题。 首先对于有自增长值的列的并发插入性能较差事务必须等待前一个插入的完成虽然不用等待事务的完成。 其次对于INSERT … SELECT的大量数据的插入会影响插入的性能因为另一个事务中的插入会被阻塞。 从MySQL 5.1.22版本开始InnoDB存储引擎中提供了一种轻量级互斥的自增长机制这种机制大大提高了自增长值插入的性能。且从该版本开始InnoDB存储引擎提供了一个参数innodb_automic_lock_mode来控制自增长的模式该参数的默认值为1。 在继续讨论自增长实现方式之前先对自增长的插入进行分类。 插入类型说明insert-like只所有的插入语句如INSERTREPLACE、LOAD DATA等等simple inserts只能在插入前就确定插入行树的语句。包括INSERT、REPLACE等。不包括INSERT … ON DUPLICATE KEY UPDATE这类SQL语句bulk inserts指在插入前不能确定得到插入行数的语句如INSERT … SELECT, REPLACE … SELECT, LOAD DATAmixed-mode inserts指插入中有一部分是自增长一部分是确定的。如INSERT INTO t1(c1,c2) VALUES(1, ‘a’), (NULL,‘b’),(5,‘c’)也可以是指INSERT … ON DUPLICATE KEY UPDATE这类SQL语句 接下来分析innodb_autoinc_lock_mode以及各个设置下对自增的影响其总共有三个有效值可供设定即0、1、2具体如下所示 为0时 MySQL5.1.22之前的实现方式通过表锁AUTO-INC Locking方式。因为有了新的自增长实现方式0这个选项不应该是新版用户的首选项。 为1时 这是默认值。对于“simple inserts”该值会用互斥量mutex去对内存中的计数器进行累加的操作。对于“bulk inserts”还是使用传统表锁的AUTO-INC Locking方式。在这种配置下如果不考虑回滚操作对于自增值列的增长还是连续的。 注意如果已经使用AUTO-INC Locing方式去产生自增长的值而这时需要再进行“simple inserts”的操作时还是需要等待AUTO-INC Locking的释放 为2时 该模式下对于所有“INSERT-like”自增长值的产生都是通过互斥量而不是AUTO-INC Locking方式该模式下性能最高。 然而因为并发插入的存在在每次插入时自增长可能不是连续的。最重要的是基于Statement-Base Replication会出现问题。因此使用这个模式任何时候都应该使用row-base replication。这样才能保证最大的并发性能及replication主从数据的一致。 注意事项 MyISAM与InnoDB的区别 还需要特别注意InnoDB中自增长的实现和MyISAM不同MyISAM是表锁设计自增长不用考虑并发插入的问题。 因此在master上用InnoDB存储引擎在slave上用MyISAM存储引擎的replication架构下用户必须考虑这种情况。 注意用索引 在InnoDB中自增长的列必须是索引同时必须是索引的第一个列。如果不是第一个列则MySQL数据库会抛出异常而MyISAM存储引擎没有这个问题。 外键和锁 外键主要用于引用完整性的约束检查。 在InnoDB中对于一个外键列如果没有显式地对这个列加索引InnoDB会自动对其加一个索引因为这样可以避免表锁。而Oracle不会自动增加索引用户必须自己手动添加这也导致了Oracle数据库中可能会产生死锁。 对于外键值的插入或更新首先需要查询父表中的记录即SELECT父表。 但是对于父表的SELECT操作不是使用一致性非锁定读的方式因为这样会发生数据不一致的问题。 因此这时使用的是SELECT … LOCK IN SHARE MODE方式即主动对浮标加一个S锁。如果这时父表上已经这样加X锁子表上的操作会被阻塞。 参考了这里