MySQL InnoDB锁机制之Gap Lock、Next-Key Lock、Record Lock解析

InnoDB是一个支持行锁的存储引擎,锁的类型有:共享锁(S)、排他锁(X)、意向共享(IS)、意向排他(IX)。为了提供更好的并发,InnoDB提供了非锁定读:不需要等待访问行上的锁释放,读取行的一个快照。该方法是通过InnoDB的一个特性:MVCC来实现的。

InnoDB有三种行锁的算法:

1,Record Lock:单个行记录上的锁。

2,Gap Lock:间隙锁,锁定一个范围,但不包括记录本身。GAP锁的目的,是为了防止同一事务的两次当前读,出现幻读的情况。

3,Next-Key Lock:1+2,锁定一个范围,并且锁定记录本身。对于行的查询,都是采用该方法,主要目的是解决幻读的问题。

锁的是索引,并不是记录。
记录锁(Record Lock): 单个索引行记录上的锁
间隙锁(Gap Lock):一般是针对非唯一索引而言的.
后码锁(Next-Key Lock):记录锁和间隙锁的结合,对于InnoDB中,更新非唯一索引对应的记录,会加上Next-Key Lock。如果更新记录为空,就不能加记录锁,只能加间隙锁。

Next-Key Lock是行锁与间隙锁的组合,这样,当InnoDB扫描索引记录的时候,会首先对选中的索引记录加上行锁(Record Lock),再对索引记录两边的间隙加上间隙锁(Gap Lock)。如果一个间隙被事务T1加了锁,其它事务是不能在这个间隙插入记录的。

https://blog.csdn.net/zhanghongzheng3213/article/details/51721903

http://blog.sina.com.cn/s/blog_a1e9c7910102vnrj.html

https://www.cnblogs.com/zhoujinyi/p/3435982.html

http://hedengcheng.com/?p=771

聚簇索引概念(Myisam与Innodb索引的区别)转推荐

myisam的主索引和次索引都指向物理行,下面来进行讲解

innodb的主键下存储该行的数据,此索引指向对主键的引用

myisam的索引存储图如下,可以看出,无论是id还是cat_id,下面都存储有存储物理地址的值。通过主键索引或者次索引来查询数据的时候,都是先查找到数据地址,然后再到物理位置上去寻找数据

innodb的索引存储图如下,我们会发现,主键索引下面直接存储有数据,而次索引下,存储的是主键的id(不同于MyISAM,存储的是内容数据的物理地址。通过主键查找数据的时候,就会很快查找到数据,但是通过次索引查找数据的时候,需要先查找到对应的主键id,然后才能查找到对应的数据。 Continue reading

Mysql Innodb的两种表空间方式

要说表空间,Mysql的表空间管理远远说不上完善。换句话说,事实上Mysql根本没有真正意义上的表空间管理。Mysql的Innodb包含两种表空间文件模式,默认的共享表空间和每个表分离的独立表空间。只要在my.cnf里面增加innodb_file_per_table=1就可以从共享表空间切换到独立表空间。当然对于已经存在的表,则需要执行alter table MY_TABLE engine=innodb命令迁移数据。

共享表空间方式

由于是默认的方式,就暂且理解为Mysql官方推荐的方式。相对而言所有的数据都在一个(或几个)文件中,比较利于管理,而且在操作的时候只需要open这一个(或几个)文件即可,相对来说代价很低。

但问题是在数据达到以G为单位来计算的时候优劣逆转。一个大小惊人的文件很不利于管理,而且对于一个如此巨大的文件来说,读写它需要耗费的资源一样巨大。更加令人费解的是,MySQL竟然将索引和数据保存于同一个文件中,索引和数据之间尚存在资源争用,不利于性能的提升。你当然可以通过innodb_data_file_path的配置规划多个表空间文件,但MySQL的逻辑是“用满后增加”,仅仅是一个文件的拆分而已,不能从根本上分离数据和索引。 Continue reading

[MySQL优化案例]系列 — 索引、提交频率对InnoDB表写入速度的影响

本次,我们通过对比,明明白白的知道索引、提交频率对InnoDB表写入速度的影响,了解有哪些需要注意的。

先直接说几个结论吧:

1、关于索引对写入速度的影响:
a、如果有自增列做主键,相对完全没索引的情况,写入速度约提升 3.11%;
b、如果有自增列做主键,并且二级索引,相对完全没索引的情况,写入速度约降低 27.37%;

因此,InnoDB表最好总是有一个自增列做主键

2、关于提交频率对写入速度的影响(以表中只有自增列做主键的场景,一次写入数据30万行数据为例):

a、等待全部数据写入完成后,最后再执行commit提交的效率最高;
b、每10万行提交一次,相对一次性提交,约慢了1.17%;
c、每1万行提交一次,相对一次性提交,约慢了3.01%;
d、每1千行提交一次,相对一次性提交,约慢了23.38%;
e、每100行提交一次,相对一次性提交,约慢了24.44%;
f、每10行提交一次,相对一次性提交,约慢了92.78%;
g、每行提交一次,相对一次性提交,约慢了546.78%,也就是慢了5倍;

因此,最好是等待所有事务结束后再批量提交,而不是每执行完一个SQL就提交一次

Continue reading

[MySQL FAQ]系列 — 为什么InnoDB表要建议用自增列做主键

我们先了解下InnoDB引擎表的一些关键特征:

  • InnoDB引擎表是基于B+树的索引组织表(IOT);
  • 每个表都需要有一个聚集索引(clustered index);
  • 所有的行记录都存储在B+树的叶子节点(leaf pages of the tree);
  • 基于聚集索引的增、删、改、查的效率相对是最高的;
  • 如果我们定义了主键(PRIMARY KEY),那么InnoDB会选择其作为聚集索引;
  • 如果没有显式定义主键,则InnoDB会选择第一个不包含有NULL值的唯一索引作为主键索引;
  • 如果也没有这样的唯一索引,则InnoDB会选择内置6字节长的ROWID作为隐含的聚集索引(ROWID随着行记录的写入而主键递增,这个ROWID不像ORACLE的ROWID那样可引用,是隐含的)。

综上总结,如果InnoDB表的数据写入顺序能和B+树索引的叶子节点顺序一致的话,这时候存取效率是最高的,也就是下面这几种情况的存取效率最高:

  • 使用自增列(INT/BIGINT类型)做主键,这时候写入顺序是自增的,和B+数叶子节点分裂顺序一致;
  • 该表不指定自增列做主键,同时也没有可以被选为主键的唯一索引(上面的条件),这时候InnoDB会选择内置的ROWID作为主键,写入顺序和ROWID增长顺序一致;
  • 除此以外,如果一个InnoDB表没有显式主键,但有可以被选择为主键的唯一索引,且该唯一索引可能不是递增关系时(例如字符串、UUID、多字段联合唯一索引的情况),该表的存取效率就会特别差。

实际情况是如何呢?经过简单TPCC基准测试,修改为使用自增列作为主键与原始表结构分别进行TPCC测试,前者的TpmC结果比后者高9%倍,足见使用自增列做InnoDB表主键的明显好处,其他更多不同场景下使用自增列的性能提升可以自行对比测试下。 Continue reading

mysql-Innodb事务隔离级别-repeatable read详解(转)

https://www.cnblogs.com/zhoujinyi/p/3437475.html

其中对“幻读”进行了详情说明,以前对这个词的理解有些偏差。

④ 幻读:第一个事务对一个表中的数据进行了修改,这种修改涉及到表中的全部数据行。同时,第二个事务也修改这个表中的数据,这种修改是向表中插入一行新数据。那么,以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行,就好象发生了幻觉一样。

mysql>CREATE TABLE `t_bitfly` (
`id` bigint(20) NOT NULL default '0',
`value` varchar(32) default NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB

mysql> select @@global.tx_isolation, @@tx_isolation;
+-----------------------+-----------------+
| @@global.tx_isolation | @@tx_isolation  |
+-----------------------+-----------------+
| REPEATABLE-READ       | REPEATABLE-READ |
+-----------------------+-----------------+

实验一:

t Session A                   Session B
|
| START TRANSACTION;          START TRANSACTION;
|
| SELECT * FROM t_bitfly;
| empty set
|                             INSERT INTO t_bitfly
|                             VALUES (1, 'a');
|
| SELECT * FROM t_bitfly;
| empty set
|                             COMMIT;
|
| SELECT * FROM t_bitfly;
| empty set
|
| INSERT INTO t_bitfly VALUES (1, 'a');
| ERROR 1062 (23000):
| Duplicate entry '1' for key 1
v (shit, 刚刚明明告诉我没有这条记录的)

如此就出现了幻读,以为表里没有数据,其实数据已经存在了,傻乎乎的提交后,才发现数据冲突了。

实验二:

t Session A                  Session B
|
| START TRANSACTION;         START TRANSACTION;
|
| SELECT * FROM t_bitfly;
| +------+-------+
| | id   | value |
| +------+-------+
| |    1 | a     |
| +------+-------+
|                            INSERT INTO t_bitfly
|                            VALUES (2, 'b');
|
| SELECT * FROM t_bitfly;
| +------+-------+
| | id   | value |
| +------+-------+
| |    1 | a     |
| +------+-------+
|                            COMMIT;
|
| SELECT * FROM t_bitfly;
| +------+-------+
| | id   | value |
| +------+-------+
| |    1 | a     |
| +------+-------+
|
| UPDATE t_bitfly SET value='z';
| Rows matched: 2  Changed: 2  Warnings: 0
| (怎么多出来一行)
|
| SELECT * FROM t_bitfly;
| +------+-------+
| | id   | value |
| +------+-------+
| |    1 | z     |
| |    2 | z     |
| +------+-------+

本事务中第一次读取出一行,做了一次更新后,另一个事务里提交的数据就出现了。也可以看做是一种幻读。
当隔离级别是可重复读,且禁用innodb_locks_unsafe_for_binlog的情况下,在搜索和扫描index的时候使用的next-key locks可以避免幻读。

mysql中innodb表的count优化

作/译者:叶金荣(imysql#imysql.com>),来源:http://imysql.com,欢迎转载。

起因:在innodb表上做count(*)统计实在是太慢了,因此想办法看能不能再快点。
现象:先来看几个测试案例,如下
一、 sbtest 表上的测试

show create table sbtest\G
*************************** 1. row ***************************
Table: sbtest
Create Table: CREATE TABLE `sbtest` (
`aid` bigint(20) unsigned NOT NULL auto_increment,
`id` int(10) unsigned NOT NULL default '0',
`k` int(10) unsigned NOT NULL default '0',
`c` char(120) NOT NULL default '',
`pad` char(60) NOT NULL default '',
PRIMARY KEY  (`aid`),
KEY `k` (`k`),
KEY `id` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1000001 DEFAULT CHARSET=latin1

show index from sbtest;
+--------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
| Table  | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
+--------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
| sbtest |          0 | PRIMARY  |            1 | aid         | A         |     1000099 |     NULL | NULL   |      | BTREE      |         |
| sbtest |          1 | k        |            1 | k           | A         |          18 |     NULL | NULL   |      | BTREE      |         |
| sbtest |          1 | id       |            1 | id          | A         |     1000099 |     NULL | NULL   |      | BTREE      |         |
+--------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+

填充了 100万条 记录。

show index from 表名介绍:http://blog.haohtml.com/archives/1889 Continue reading

MySQL技术内幕:InnoDB存储-3.6 InnoDB存储引擎文件

3.6   InnoDB存储引擎文件
之前介绍的文件都是MySQL数据库本身的文件,和存储引擎无关。除了这些文件外,每个表存储引擎还有其自己独有的文件。这一节将具体介绍和InnoDB存储引擎密切相关的文件,这些文件包括重做日志文件、表空间文件。
3.6.1   表空间文件
InnoDB存储引擎在存储设计上模仿了Oracle,将存储的数据按表空间进行存放。默认配置下,会有一个初始化大小为10MB、名为ibdata1的文件。该文件就是默认的表空间文件(tablespace file)。你可以通过参数innodb_data_file_path对其进行设置。格式如下:
innodb_data_file_path=datafile_spec1[;datafile_spec2]…
你也可以用多个文件组成一个表空间,同时制定文件的属性,如: Continue reading

[存储引擎基础知识]InnoDB与MyISAM的六大区别

这其实是09年总结的一篇文章,今天被一位朋友问到InnoDB有什么好处,一下子讲不清楚,现在把在自己另外一个博客的文章在这里重发一遍,主要是讲InnoDB和MyISAM的对比,从中可以看到InnoDB的很多好处,比如并发插入的时候行级锁等

本 文主要整理了Mysql 两大常用的存储引擎MyISAM,InnoDB的六大常见区别,来源于Mysql手册以及互联网的资料

InnoDBMyisam的六大区别
MyISAM InnoDB
构 成上的区别: 每个MyISAM在磁盘上存储成三个文件。第一个 文件的名字以表的名字开始,扩展名指出文件类型。

.frm文件存储表定义。

数据文件的扩 展名为.MYD (MYData)。

索引文件的扩 展名是.MYI (MYIndex)。

基于磁盘的资源是InnoDB表空间数据文件和它的日志文件,InnoDB 表的 大小只受限于操作系统文件的大小,一般为 2GB
事务处理上方面: MyISAM类型的表强调的是性能,其执行数 度比InnoDB类型更快,但是不提供事务支持 InnoDB提供事务支持事务,外部键等高级 数据库功能
SELECT UPDATE,INSERTDelete操 作 如果执行大量的SELECT,MyISAM是更好的选择 1.如果你的数据执行大量的INSERTUPDATE,出于性能方面的考虑,应该使用InnoDB表

2.DELETE FROM table时,InnoDB不会重新建立表,而是一行一行的 删除。

3.LOAD TABLE FROM MASTER操作对InnoDB是不起作用的,解决方法是首先把InnoDB表改成MyISAM表,导入数据后再改成InnoDB表,但是对于使用的额外的InnoDB特性(例如外键)的表不适用

AUTO_INCREMENT的 操作

每表一个AUTO_INCREMEN列的内部处理。

MyISAMINSERTUPDATE操 作自动更新这一列。这使得AUTO_INCREMENT列更快(至少10%)。在序列顶的值被删除之后就不 能再利用。(当AUTO_INCREMENT列被定义为多列索引的最后一列, 可以出现重使用从序列顶部删除的值的情况)。

AUTO_INCREMENT值可用ALTER TABLE或myisamch来重置

对于AUTO_INCREMENT类型的字段,InnoDB中必须包含只有该字段的索引,但 是在MyISAM表中,可以和其他字段一起建立联 合索引

更好和更快的auto_increment处理

如果你为一个表指定AUTO_INCREMENT列,在数据词典里的InnoDB表句柄包含一个名为自动增长计数 器的计数器,它被用在为该列赋新值。

自动增长计数 器仅被存储在主内存中,而不是存在磁盘上

关于该计算器 的算法实现,请参考

AUTO_INCREMENT列 在InnoDB里 如何工作

表 的具体行数 select count(*) from table,MyISAM只要简单的读出保存好的行数,注意的是,当count(*)语句包含 where条件时,两种表的操作是一样的 InnoDB 中不 保存表的具体行数,也就是说,执行select count(*) from table时,InnoDB要扫描一遍整个表来计算有多少行
表锁 提供行锁(locking on row level),提供与 Oracle 类型一致的不加锁读取(non-locking read in
SELECTs),另外,InnoDB表的行锁也不是绝对的,如果在执 行一个SQL语句时MySQL不能确定要扫描的范围,InnoDB表同样会锁全表,例如update table set num=1 where name like “%aaa%”
本文原出处为 http://www.dbahacker.com

转载烦请保留 链接