InnoDB事务锁之行锁-delete search阶段加锁原理图-聚集索引

2023-11-12 来源：华拓网

标签：innodb nod img src sea com ima 原理图 vpd

小编还为您整理了以下内容，可能对您也有帮助：

Innodb锁机制

InnoDB实现了两种类型的行锁。

共享锁（S）：允许一个事务去读一行，阻止其他事务获得相同的数据集的排他锁。

排他锁（X）：允许获得排他锁的事务更新数据，但是组织其他事务获得相同数据集的共享锁和排他锁。

可以这么理解：

共享锁就是我读的时候，你可以读，但是不能写。排他锁就是我写的时候，你不能读也不能写。其实就是MyISAM的读锁和写锁，但是针对的对象不同了而已。

除此之外InnoDB还有两个表锁：

意向共享锁（IS）：表示事务准备给数据行加入共享锁，也就是说一个数据行加共享锁前必须先取得该表的IS锁

意向排他锁（IX）：类似上面，表示事务准备给数据行加入排他锁，说明事务在一个数据行加排他锁前必须先取得该表的IX锁。

意向锁是InnoDB自动加的，不需要用户干预。

对于insert、update、delete，InnoDB会自动给涉及的数据加排他锁（X）；对于一般的Select语句，InnoDB不会加任何锁，事务可以通过以下语句给显示加共享锁或排他锁。

共享锁：select * from table_name where .....lock in share mode

排他锁：select * from table_name where .....for update

InnoDB行锁是通过给索引项加锁实现的，索引分为主键索引和非主键索引两种，如果一条 sql语句操作了主键索引，MySQL就会锁定这条主键索引;如果一条语句操作了非主键索引，MySQL会先锁定该非主键索引，再锁定相关的主键索引，如果没有索引，InnoDB会通过隐藏的聚簇索引来对记录加锁。也就是说：如果不通过索引条件检索数据，那么InnoDB将对表中所有数据加锁，实际效果跟表锁一样。

InnoDB对于行的查询都是采用了Next-Key Lock的算法，锁定的不是单个值，而是一个范围（GAP）。上面索引值有1，3，5，8，11，其记录的GAP的区间如下：是一个左开右闭的空间（原因是默认主键的有序自增的特性，结合后面的例子说明）

（-∞,1]，(1,3]，(3,5]，(5,8]，(8,11]，(11,+∞）

InnoDB对于行的查询都是采用了Next-Key Lock的算法，锁定的不是单个值，而是一个范围，按照这个方法是会和第一次测试结果一样。但是，当查询的索引含有唯一属性的时候，Next-Key Lock 会进行优化，将其降级为Record Lock，即仅锁住索引本身，不是范围。

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

Innodb锁机制

mysql存储引擎区别有哪些

MySQL中存储引擎的区别：以Innodb和myisam为例，前者支持事务而后者不支持；前者强调多功能性，支持的拓展功能比较多，后者主要侧重于性能；前者不支持全文索引，而后者支持全文索引等

mysql支持存储引擎有好几种，咱们这里主要讨论一下常用的几种存储引擎。Innodb，myisam
INNODB
INNODB索引实现
与 MyISAM相同的一点是，InnoDB 也采用 B+Tree这种数据结构来实现 B-Tree索引。而很大的区别在于，InnoDB 存储引擎采用“聚集索引”的数据存储方式实现B-Tree索引，所谓“聚集”，就是指数据行和相邻的键值紧凑地存储在一起，注意 InnoDB 只能聚集一个叶子页（16K）的记录（即聚集索引满足一定的范围的记录），因此包含相邻键值的记录可能会相距甚远。
在 InnoDB 中，表被称为索引组织表（index organized table），InnoDB 按照主键构造一颗 B+Tree （如果没有主键，则会选择一个唯一的并且非空索引替代，如果没有这样的索引，InnoDB则会隐式地定义一个主键来作为聚集索引），同时叶子页中存放整张表的行记录数据，也可以将聚集索引的叶子节点称为数据页，非叶子页可以看做是叶子页的稀疏索引。
下图说明了 InnoDB聚集索引的实现方式，同时也体现了一张 innoDB表的结构，可以看到，InnoDB 中，主键索引和数据是一体的，没有分开。
这种实现方式，给予了 InnoDB 按主键检索的超高性能。可以有目的性地选择聚集索引，比如一个邮件表，可以选择用户ID来聚集数据，这样只需要从磁盘读取较少并且连续的数据页就能获得某个id的用户全部的邮件，避免了读取分散页时所耗费的随机I/O。
InnoDB 则是 I/O 操作，Innodb读写采用MVCC来支持高并发。
全表扫描
当InnoDB做全表扫描时并不高效，因为 InnoDB 实际上并没有顺序读取,在大多情况下是在随机读取。做全表扫描时,InnoDB 会按主键顺序扫描页面和行。这应用于所有的InnoDB 表，包括碎片化的表。如果主键页表没有碎片（存储主键和行的页表),全表扫描是相当快，因为读取顺序接近物理存储顺序。但是当主键页有碎片时，该扫描就会变得十分缓慢
行级锁
提供行锁(locking on row level)，提供与 Oracle 类型一致的不加锁读取(non-locking read in SELECTs)，另外，InnoDB表的行锁也不是绝对的，如果在执行一个SQL语句时MySQL不能确定要扫描的范围，InnoDB表同样会锁全表，例如
update table set num=1 where name like “%aaa%”MYISAM
MyISAM索引的实现
每个MyISAM在磁盘上存储成三个文件。第一个文件的名字以表的名字开始，扩展名指出文件类型。MyISAM索引文件【.MYI (MYIndex)】和数据文件【.MYD (MYData)】是分离的，索引文件仅保存记录所在页的指针（物理位置），通过这些地址来读取页，进而读取被索引的行。先来看看结构图
上图很好地说明了树中叶子保存的是对应行的物理位置。通过该值，存储引擎能顺利地进行回表查询，得到一行完整记录。同时，每个叶子页也保存了指向下一个叶子页的指针。从而方便叶子节点的范围遍历。而对于二级索引，在 MyISAM存储引擎中以与上图同样的方式实现，这也说明了 MyISAM的索引方式是“非聚集的”，与 Innodb的“聚集索引”形成了对比
MyISAM 默认会把索引读入内存，直接在内存中操作；
表级锁
小结：Innodb强调多功能性，支持的拓展功能比较多，myisam主要侧重于性能
区别
1、InnoDB支持事务，MyISAM不支持，对于InnoDB每一条SQL语言都默认封装成事务，自动提交，这样会影响速度，所以最好把多条SQL语言放在begin和commit之间，组成一个事务；
2、InnoDB是聚集索引，数据文件是和索引绑在一起的，必须要有主键，通过主键索引效率很高。但是辅助索引需要两次查询，先查询到主键，然后再通过主键查询到数据。因此，主键不应该过大，因为主键太大，其他索引也都会很大。而MyISAM是非聚集索引，数据文件是分离的，索引保存的是数据文件的指针。主键索引和辅助索引是独立的。
3、InnoDB不保存表的具体行数，执行select count(*) from table时需要全表扫描。而MyISAM用一个变量保存了整个表的行数，执行上述语句时只需要读出该变量即可，速度很快；
4、Innodb不支持全文索引，而MyISAM支持全文索引，查询效率上MyISAM要高；

mysql存储引擎区别有哪些

MySQL中innodb的行锁算法

众所周知，innodb是默认行锁，当然也支持表锁。如下是对于行锁的算法进行的一些实验。

锁的算法为：我知道是行锁，但是是如何锁的，锁多少数据

假如有个索引是：[1，2，3，7]
record lock 锁的是 1，2，3，7
gap lock 锁的是 (- ，1)，（2，3），（3，7），（7，+ ）反正锁的就是区间，不是行
next-key lock锁的是 (- ，1]，[2，3），[3，7），[ 7，+ ）既锁范围也锁行

Innodb锁算法规则如下：

在可重复读隔离级别下，innodb默认使用的是next-key lock算法，当查询的索引是主键或者唯一索引的情况下，才会退化为record lock，在使用next-key lock算法时，不仅仅会锁住范围，还会给范围最后的一个键值加一个gap lock。

其中lockmode中的X锁为左边会话中的锁，因为需要显式的commit之后才会释放锁，第二个S锁，为右边的共享锁，因为主键ID为1的已经被锁住了，所以处于锁等待状态，锁的类型为record lock

使用辅助索引a=8进行操作，这个时候理论应该对主键索引加record lock 则主键ID=8的被锁，然后辅助索引被加next-key lock 则为：
(7,8] 然后对下一个键值加gap锁，则为：（8，11）
所以目前被锁住的记录为：
1.主键为8的被锁
2.辅助索引8的被锁
3.辅助索引8到11之间的被锁，意味着你这个时候往8到11之间写数据会报错

当使用范围条件进行更新时，此时肯定是需要加X锁的，我是用的也是主键，所以按照理论应该是加的record lock ,但是却加了gap lock，因为插入值为10的阻塞了，查看information 也提示X.GAP
这个有点晕为啥主键变成了next-key lock ，不应该是record lock么？
update20200515
在知乎看到的一个解释：

即，在无论使用主键索引还是非主键索引的时候，请求共享锁或者排他锁，innodb会给范围内的记录加锁，而范围内的间隙也会被加锁，
例如一个表t 的 id为1，2，3，7，10
假如执行如下：
select * from t where id >=3 for update
那么这个时候执行
insert into t(id) values(8) 会被阻塞，因为是在请求排他锁时使用了范围，所以[3,10],甚至10以后的任何数据都无法插入。
执行
select * from t where id >=3 lock in share mode
insert into t(id) values(8) 会被阻塞，因为是在请求共享锁时使用了范围，所以[3,10],甚至10以后的任何数据都无法插入。

幻读是同一事务下，连续执行两次同样的sql可能导致不同的结果，第二次返回的数据可能导致以前不存在的行。
同时一般会问它和脏读的区别，脏读为读取到其他事务未提交的数据，但是幻读是读取的其他事务已经提交的数据。

reference：

MySQL中innodb的行锁算法

众所周知，innodb是默认行锁，当然也支持表锁。如下是对于行锁的算法进行的一些实验。

锁的算法为：我知道是行锁，但是是如何锁的，锁多少数据

Innodb锁算法规则如下：

reference：

详解MySQL（InnoDB）是如何处理死锁的

一、什么是死锁

官方定义如下：两个事务都持有对方需要的锁，并且在等待对方释放，并且双方都不会释放自己的锁。

这个就好比你有一个人质，对方有一个人质，你们俩去谈判说换人。你让对面放人，对面让你放人。

二、为什么会形成死锁

看到这里，也许你会有这样的疑问，事务和谈判不一样，为什么事务不能使用完锁之后立马释放呢？居然还要操作完了之后一直持有锁？这就涉及到 MySQL 的并发控制了。

MySQL的并发控制有两种方式，一个是 MVCC，一个是两阶段锁协议。那么为什么要并发控制呢？是因为多个用户同时操作 MySQL 的时候，为了提高并发性能并且要求如同多个用户的请求过来之后如同串行执行的一样（可串行化调度）。具体的并发控制这里不再展开。咱们继续深入讨论两阶段锁协议。

两阶段锁协议（2PL）

官方定义：

两阶段锁协议是指所有事务必须分两个阶段对数据加锁和解锁，在对任何数据进行读、写操作之前，事务首先要获得对该数据的封锁；在释放一个封锁之后，事务不再申请和获得任何其他封锁。

对应到 MySQL 上分为两个阶段：

扩展阶段（事务开始后，commit 之前）：获取锁

收缩阶段（commit 之后）：释放锁

就是说呢，只有遵循两段锁协议，才能实现可串行化调度。

但是两阶段锁协议不要求事务必须一次将所有需要使用的数据加锁，并且在加锁阶段没有顺序要求，所以这种并发控制方式会形成死锁。

三、MySQL 如何处理死锁？

MySQL有两种死锁处理方式：

等待，直到超时（innodb_lock_wait_timeout=50s）。

发起死锁检测，主动回滚一条事务，让其他事务继续执行（innodb_deadlock_detect=on）。

由于性能原因，一般都是使用死锁检测来进行处理死锁。

死锁检测

死锁检测的原理是构建一个以事务为顶点、锁为边的有向图，判断有向图是否存在环，存在即有死锁。

回滚

检测到死锁之后，选择插入更新或者删除的行数最少的事务回滚，基于 INFORMATION_SCHEMA.INNODB_TRX 表中的 trx_weight 字段来判断。

四、如何避免发生死锁

收集死锁信息：

利用命令 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 锁多张表

详解MySQL（InnoDB）是如何处理死锁的

标签：orm事务开启协议mysqinf无法图片收集

MySQL简单介绍——换个角度认识MySQL

1、InnoDB存储引擎

Mysql版本>=5.5 默认的存储引擎，MySQL推荐使用的存储引擎。支持事务，行级锁定，外键约束。事务安全型存储引擎。更加注重数据的完整性和安全性。

存储格式 : 数据，索引集中存储，存储于同一个表空间文件中。

InnoDB的行锁模式及其加锁方法： InnoDB中有以下两种类型的行锁：共享锁（读锁：允许事务对一条行数据进行读取）和互斥锁（写锁：允许事务对一条行数据进行删除或更新），对于update，insert，delete语句，InnoDB会自动给设计的数据集加互斥锁，对于普通的select语句，InnoDB不会加任何锁。

InnoDB行锁的实现方式： InnoDB行锁是通过给索引上的索引项加锁来实现的，如果没有索引，InnoDB将通过隐藏的聚簇索引来对记录加锁。InnoDB这种行锁实现特点意味着：如果不通过索引条件检索数据，那么InnoDB将对表中的所有记录加锁，实际效果跟表锁一样。

（1）在不通过索引条件查询时，InnoDB会锁定表中的所有记录。

（2）Mysql的行锁是针对索引加的锁，不是针对记录加的锁，所以虽然是访问不同行的记录，但是如果使用相同的索引键，是会出现冲突的。

（3）当表有多个索引的时候，不同的事务可以使用不同的索引锁定不同的行，但都是通过行锁来对数据加锁。

优点：

1、支持事务处理、ACID事务特性；

2、实现了SQL标准的四种隔离级别（原子性（ Atomicity ）、一致性（ Consistency ）、隔离性（Isolation ）和持续性（Durability ））；

3、支持行级锁和外键约束；

4、可以利用事务日志进行数据恢复。

5、锁级别为行锁，行锁优点是适用于高并发的频繁表修改，高并发是性能优于 MyISAM。缺点是系统消耗较大。

6、索引不仅缓存自身，也缓存数据，相比 MyISAM 需要更大的内存。

缺点：

因为它没有保存表的行数，当使用COUNT统计时会扫描全表。

使用场景：

(1)可靠性要求比较高，或者要求事务；(2)表更新和查询都相当的频繁，并且表锁定的机会比较大的情况。

2、 MyISAM存储引擎

MySQL<= 5.5 MySQL默认的存储引擎。ISAM：Indexed Sequential Access Method(索引顺序存取方法)的缩写，是一种文件系统。擅长与处理，高速读与写。

功能：

（1）支持数据压缩存储,但压缩后的表变成了只读表，不可写；如果需要更新数据，则需要先解压后更新。

（2）支持表级锁定，不支持高并发；

（3）支持并发插入。写操作中的插入操作，不会阻塞读操作（其他操作）；

优点：

1.高性能读取；

2.因为它保存了表的行数，当使用COUNT统计时不会扫描全表；

缺点：

1、锁级别为表锁，表锁优点是开销小，加锁快；缺点是锁粒度大，发生锁冲动概率较高，容纳并发能力低，这个引擎适合查询为主的业务。

2、此引擎不支持事务，也不支持外键。

3、INSERT和UPDATE操作需要锁定整个表；

使用场景：

(1)做很多count 的计算；(2)插入不频繁，查询非常频繁；(3)没有事务。

InnoDB和MyISAM一些细节上的差别：

1、InnoDB不支持FULLTEXT类型的索引，MySQL5.6之后已经支持（实验性）。

2、InnoDB中不保存表的具体行数，也就是说，执行select count() from table时，InnoDB要扫描一遍整个表来计算有多少行，但是MyISAM只要简单的读出保存好的行数即可。注意的是，当count()语句包含 where条件时，两种表的操作是一样的。

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

4、DELETE FROM table时，InnoDB不会重新建立表，而是一行一行的删除。

5、LOAD TABLE FROM MASTER操作对InnoDB是不起作用的，解决方法是首先把InnoDB表改成MyISAM表，导入数据后再改成InnoDB表，但是对于使用的额外的InnoDB特性（例如外键）的表不适用。

6、另外，InnoDB表的行锁也不是绝对的，如果在执行一个SQL语句时MySQL不能确定要扫描的范围，InnoDB表同样会锁全表。

1．索引概述

利用关键字，就是记录的部分数据（某个字段，某些字段，某个字段的一部分），建立与记录位置的对应关系，就是索引。索引的关键字一定是排序的。索引本质上是表字段的有序子集，它是提高查询速度最有效的方法。一个没有建立任何索引的表，就相当于一本没有目录的书，在每次查询时就会进行全表扫描，这样会导致查询效率极低、速度也极慢。如果建立索引，那么就好比一本添加的目录，通过目录的指引，迅速翻阅到指定的章节，提升的查询性能，节约了查询资源。

2．索引种类

从索引的定义方式和用途中来看：主键索引，唯一索引，普通索引，全文索引。

无论任何类型，都是通过建立关键字与位置的对应关系来实现的。索引是通过关键字找对应的记录的地址。

以上类型的差异：对索引关键字的要求不同。

关键字：记录的部分数据（某个字段，某些字段，某个字段的一部分）。

普通索引,index：对关键字没有要求。

唯一索引,unique index：要求关键字不能重复。同时增加唯一约束。

主键索引,primary key：要求关键字不能重复，也不能为NULL。同时增加主键约束。

全文索引,fulltext key：关键字的来源不是所有字段的数据，而是从字段中提取的特别关键词。

PS：这里主键索引和唯一索引的区别在于：主键索引不能为空值，唯一索引允许空值；主键索引在一张表内只能创建一个，唯一索引可以创建多个。主键索引肯定是唯一索引，但唯一索引不一定是主键索引。

3.索引原则

如果索引不遵循使用原则，则可能导致索引无效。

（1）列

如果需要某个字段上使用索引，则需要在字段参与的表达中，保证字段在一侧。否则索引不会用到索引, 例如这条sql就不会用到索引:select * from A where id+1=10;

（2）左原则

Like：匹配模式必须要左边确定不能以通配符开头。例如:select * from A where name like '%小明%' ，不会用到索引，而select * from A where name like '小明%' 就可以用到索引（name字段有建立索引），如果业务上需要用到'%小明%'这种方式,有两种方法:1.可以考虑全文索引,但mysql的全文索引不支持中文；2.只查询索引列或主键列,例如:select name from A where name like '%小明%' 或 select id from A where name like '%小明%' 或 select id,name from A where name like '%小明%' 这三种情况都会用到name的索引;

复合索引：一个索引关联多个字段，仅仅针对左边字段有效果，添加复合索引时，第一个字段很重要，只有包含第一个字段作为查询条件的情况才会使用复合索引(必须用到建索引时选择的第一个字段作为查询条件,其他字段的顺序无关),而且查询条件只能出现and拼接,不能用or,否则则无法使用索引.

（3）OR的使用

必须要保证 OR 两端的条件都存在可以用的索引，该查询才可以使用索引。

（4）MySQL智能选择

即使满足了上面说原则，MySQL也能弃用索引，例如：select * from A where id > 1;这里弃用索引的主要原因：查询即使使用索引，会导致出现大量的随机IO，相对于从数据记录的第一条遍历到最后一条的顺序IO开销，还要大。

4.索引的使用场景

（1）索引检索：检索数据时使用索引。

（2）索引排序: 如果order by 排序需要的字段上存在索引，则可能使用到索引。

（3）索引覆盖: 索引拥有的关键字内容，覆盖了查询所需要的全部数据，此时，就不需要在数据区获取数据，仅仅在索引区即可。覆盖就是直接在索引区获取内容，而不需要在数据区获取。例如: select name from A where name like '小明%';

建立索引索引时，不能仅仅考虑where检索，同时考虑其他的使用场景。（在所有的where字段上增加索引，就是不合理的）

5.前缀索引

前缀索引是建立索引关键字一种方案。通常会使用字段的整体作为索引关键字。有时，即使使用字段前部分数据，也可以去识别某些记录。就比如一个班级里，我要找王xx，假如姓王的只有1个人，那么就可以建一个关键字为'王'的前缀索引。语法：Index `index_name` (`index_field`(N))使用index_name前N个字符建立的索引。

6.索引失效

（1）应尽量避免在 where 子句中使用 != 或 > 操作符，否则将引擎放弃使用索引而进行全表扫描；

（2）应尽量避免在 where 子句中使用 or 来连接条件，如果一个字段有索引，一个字段没有索引，将导致引擎放弃使用索引而进行全表扫描；

（3）应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描；

（4）应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描；如select id from t where num/2 = 100；

（5）应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描；如：select id from t where substring(name,1,3) = ’abc’ ；

（6）应尽量避免在where子句中对字段进行类型转换，这将导致引擎放弃使用索引而进行全表扫描；如果列类型是字符串，那一定要在条件中将数据使用引号引用起来,如select id from t where id = 1；如果id字段在表设计中是varchar类型，那么即使id列上存的是数字，在查询时也一定要用varchar去匹配，sql应改为select id from t where id = '1'；

（7）应尽量避免在where子句中单独引用复合索引里非第一位置的索引；

join 的两种算法：BNL 和 NLJ

NLJ（Nested Loop Join）嵌套循环算法；以如下 SQL 为例：

select * from t1 join t2 on t1.a=t2.a

SQL 执行时内部流程是这样的：

1. 先从 t1（假设这里 t1 被选为驱动表）中取出一行数据 X；

2. 从 X 中取出关联字段 a 值，去 t2 中进行查找，满足条件的行取出；

3. 重复1、2步骤，直到表 t1 最后一行循环结束。

这就是一个嵌套循环的过程，如果在被驱动表上查找数据时可以使用索引，总的对比计算次数等于驱动表满足 where 条件的行数。假设这里 t1、t2都是1万行，则只需要 1万次计算，这里用到的是Index Nested-Loops Join（INLJ，基于索引的嵌套循环联接）。

如果 t1、t2 的 a 字段都没有索引，还按照上述的嵌套循环流程查找数据呢？每次在被驱动表上查找数据时都是一次全表扫描，要做1万次全表扫描，扫描行数等于 1万+1万*1万，这个效率很低，如果表行数更多，扫描行数动辄几百亿，所以优化器肯定不会使用这样的算法，而是选择 BNL 算法；

BNLJ（Block Nested Loop Join）块嵌套循环算法；

1. 把 t1 表（假设这里 t1 被选为驱动表）满足条件的数据全部取出放到线程的 join buffer 中；

2. 每次取 t2 表一行数据，去 joinbuffer 中进行查找，满足条件的行取出，直到表 t2 最后一行循环结束。

这个算法下，执行计划的 Extra 中会出现 Using join buffer(Block Nested Loop)，t1、t2 都做了一次全表扫描，总的扫描行数等于 1万+1万。但是由于 joinbuffer 维护的是一个无序数组，每次在 joinbuffer 中查找都要遍历所有行，总的内存计算次数等于1万*1万。另外如果 joinbuffer 不够大放不下驱动表的数据，则要分多次执行上面的流程，会导致被驱动表也做多次全表扫描。

BNLJ相对于NLJ的优点在于，驱动层可以先将部分数据加载进buffer，这种方法的直接影响就是将大大减少内层循环的次数，提高join的效率。

例如：

如果内层循环有100条记录，外层循环也有100条记录，这样的话，每次外层循环先将10条记录放到buffer中，内层循环的100条记录每条与这个buffer中的10条记录进行匹配，只需要匹配内层循环总记录数次即可结束一次循环（在这里，即只需要匹配100次即可结束），然后将匹配成功的记录连接后放入结果集中，接着，外层循环继续向buffer中放入10条记录，同理进行匹配，并将成功的记录连接后放入结果集。后续循环以此类推，直到循环结束，将结果集发给client为止。

可以发现，若用NLJ，则需要100 * 100次才可结束，BNLJ则需要100 / block_size * 100 = 10 * 100次就可结束,大大减少了循环次数。

JOIN 按照功能大致分为如下三类：

JOIN、STRAIGHT_JOIN、INNER JOIN（内连接,或等值连接）：取得两个表中存在连接匹配关系的记录。

LEFT JOIN（左连接）：取得左表（table1）完全记录，即是右表（table2）并无对应匹配记录。

RIGHT JOIN（右连接）：与 LEFT JOIN 相反，取得右表（table2）完全记录，即是左表（table1）并无匹配对应记录。

注意：mysql不支持Full join,不过可以通过UNION 关键字来合并 LEFT JOIN 与 RIGHT JOIN来模拟FULL join。

mysql 多表连接查询方式，因为mysql只支持NLJ算法,所以如果是小表驱动大表则效率更高；反之则效率下降；因此mysql对内连接或等值连接的方式做了一个优化,会去判断join表的数据行大小,然后取数据行小的表为驱动表。

INNER JOIN、JOIN、WHERE等值连接和STRAIGHT_JOIN都能表示内连接，那平时如何选择呢？一般情况下用INNER JOIN、JOIN或者WHERE等值连接，因为MySQL 会按照"小表驱动大表的策略"进行优化。当出现需要排序时，才考虑用STRAIGHT_JOIN指定某张表为驱动表。

两表JOIN优化

a.当无order by条件时，根据实际情况，使用left/right/inner join即可，根据explain优化；

b.当有order by条件时，如select * from a inner join b where 1=1 and other condition order by a.col；使用explain解释语句；

1）如果第一行的驱动表为a，则效率会非常高，无需优化；

2）否则，因为只能对驱动表字段直接排序的缘故，会出现using temporary，所以此时需要使用STRAIGHT_JOIN明确a为驱动表，来达到使用a.col上index的优化目的；或者使用left join且Where条件中不含b的过滤条件，此时的结果集为a的全集，而STRAIGHT_JOIN为inner join且使用a作为驱动表。注：使用STRAIGHT_JOIN虽然不会using temporary，但也不是一定就能提高效率，如果a表数据远远超过b表，那么有可能使用STRAIGHT_JOIN时比原来的sql效率更低，所以怎么使用STRAIGHT_JOIN，还是要视情况而定。

在使用left join（或right join）时，应该清楚的知道以下几点：

(1). on与 where的执行顺序

ON 条件（“A LEFT JOIN B ON 条件表达式”中的ON）用来决定如何从 B 表中检索数据行。如果 B 表中没有任何一行数据匹配 ON 的条件,将会额外生成一行所有列为 NULL 的数据,在匹配阶段 WHERE 子句的条件都不会被使用。仅在匹配阶段完成以后，WHERE 子句条件才会被使用。它将从匹配阶段产生的数据中检索过滤。

所以我们要注意：在使用Left (right) join的时候，一定要在先给出尽可能多的匹配满足条件，减少Where的执行。

(2).注意ON 子句和 WHERE 子句的不同

即使右表的数据不满足ON后面的条件,也会在结果集拼接一条为NULL的数据行,但WHERE后面的条件不一样,右表不满足WHERE的条件,左表关联的数据也会被过滤掉。

(3).尽量避免子查询，而用join

往往性能这玩意儿，更多时候体现在数据量比较大的时候，此时，我们应该避免复杂的子查询。

（1）in 和 not in 要慎用，如：select id from t where num in(1,2,3)对于连续的数值，能用 between 就不要用 in：select id from t where num between 1 and 3很多时候用 exists 代替 in 是一个好的选择：select num from a where num in(select num from b)用下面的语句替换：select num from a where exists(select 1 from b where num=a.num)

（2）Update 语句，如果只更改1、2个字段，不要Update全部字段，否则频繁调用会引起明显的性能消耗，同时带来大量日志。

（3）join语句,MySQL里面的join是用小表去驱动大表,而由于MySQL join实现的原理就是做循环，比如left join就是对左边的数据进行循环去驱动右边的表,左边有m条记录匹配,右边有n条记录那么就是做m次循环,每次扫描n行数据,总扫面行数是m*n行数据。左边返回的结果集的大小就决定了循环的次数,故单纯的用小表去驱动大表不一定的正确的,小表的结果集可能也大于大表的结果集,所以写join的时候尽可能的先估计两张表的可能结果集,用小结果集去驱动大结果集.值得注意的是在使用left/right join的时候,从表的条件应写在on之后,主表应写在where之后.否则MySQL会当作普通的连表查询；

（4）select count(*) from table；这样不带任何条件的count会引起全表扫描，并且没有任何业务意义，是一定要杜绝的；

（5）select * from t 这种语句要尽量避免，使用具体的字段代替*，更有实际意义，需要什么字段就返回什么字段；

（6）数据量大的情况下，limit要慎用，因为使用limit m，n方式分页时，mysql每次都是查询前m+n条，然后舍弃前m条，所以m越大，偏移量越大，性能就越差。比如：select * from A limit 1000000,20这钟，查询效率就会非常低，当分页的页数大于一定的数量之后，就可以换种方式来分页：select * from A a join （select id from A limit 1000000，20） b on a.id=b.id;

显示全文

全部频道

InnoDB事务锁之行锁-delete search阶段加锁原理图-聚集索引