MySql的MyIsam和InnoDb两个搜索引擎的区别与联系

版权声明：如需转载，请写明出处 https://blog.csdn.net/weixin_43113679/article/details/89425467

先来个提示，此文章是我在学习MySql的过程中看了很多的文章和博客，多的我都数不过来了，之后自己总结或者摘抄一部分，最完整的借鉴的博客(https://www.cnblogs.com/chenqionghe/articles/4845693.html)非常感谢
我自己写出来的总结感觉对我自己有用还是盲点的地方，缺少的地方请见谅

首先说MySQL

MySQl用的数据结构是B+树数据结构，而oracle用的是B树数据结构，稍微说一点，不是重点

MyIsam和InnoDb的结构区别（非聚簇和聚簇）

首先你肯定要知道MySql用的是B+树数据结构，但是B+树结构也是有区别的，比如这两个搜索引擎下的B+树的结构就有相同和区别：

1. 首先是肯定像B+树的特点一样，所有的data数据域都在叶子节点，而内结点就只有索引，节省空间
2. 叶子节点都有指向下一个叶子节点的指针，这样区间查询效率快，直接从叶子节点直接到另一个叶子节点，不用再回根节点

区别：就在那个叶子节点的data域

1. MyIsam 表包括三个文件：索引文件，表结构文件，数据文件，data中存放的是数据的地址，然后再通过数据表的堆上一行一行的去找，而不是页，文件分散，所以称为非聚簇
2. InnoDb 表中数据文件本身就是索引文件，所以data中存放的就是数据本身的值，可以直接找到值，文件聚集，所以称为聚簇
   应用的区别，对于数据量大的数据访问，就不太适合用非聚簇，而聚簇就挺适合

支持的事务

MyIsam不支持事务，但是它的操作是原子的(要不执行，要不不执行，没有执行一半的情况，可以有效避免A在修改数据时因为种种原因停下了，而这时数据修改了一半，这就会影响后面读取这个的数据操作)
InnoDb支持ACID事务，支持事务的四种隔离(重点)
事务的四种属性：

1. 原子性：和MyIsam中的一样
2. 一致性：事务开始到完成，内部数据结构不能变
3. 隔离性：数据库系统提供一定的隔离机制，保证事务独立运行，互相不受影响，执行的过程是封闭的
4. 持久性：事务完成后，对于数据修改就确定了，就算出现系统故障只要能找回数据那数据也是修改过的，除非数据都找不会来

说道事务就要说说并发

对于串行处理不会发生并发事故，但是太浪费资源和等待时间了，所以并发提高了数据的利用率，提高了数据库的吞吐量，支持更多的人操作而不用浪费时间在等待上，但是有好处就有坏处，并发操作带来了很多问题：

5. 更新丢失：因为事务互相不知道对方，当对一个数据修改后，会以最后一个提交的数据为准，前一个提交的会被覆盖，可以加锁解决，事务不知道但是获得的写锁只有一把，所以可以有效避免
6. 脏读：一个事务正在更改数据，但是另一个事务来读取数据，事务还没提交，数据就读取了，那读取的数据就是脏数据，数据存在不一致现象
7. 不可重复读：一个事务正在读取的数据正在发生改变或者被删除(比如存货为0了)，不存在了，但是还是读取了此数据，这种叫不可重复读
8. 幻读：一个事务按相同的查询条件，读取以前的数据，但是查询到其它事务插入了新的数据（就像旧数据插入了新的数据）

事务的四种隔离级别

隔离级别/读数据一致性及允许的并发副作用	读数据一致性	脏读	不可重复读	幻读
未提交读（Read uncommitted）	最低级别，只能保证不读取物理上损坏的数据	是	是	是
已提交读（Read committed）	语句级	否	是	是
可重复读（Repeatable read）	事务级	否	否	是
可序列化（Serializable）	最高级别，事务级	否	否	否

上面的四种隔离级别，数据库的事务隔离级别越高，并发操作带来的后遗症就会越小，但是付出的代价就会越大，还是那句老话，有失就有得，
事务隔离的本质就是把事务在一定程度上“串行”话，这与“并发”是有一定的矛盾的，不同应用对事务的隔离级别的要求不一样，不要所有的应用都用最高级，那代价就太大了，
比如有的应用对幻读和不可重复读没有什么敏感，更注重数据并发访问能力，
根据隔离级别的特点合理利用才是正确的，要不事务为什么出现四种隔离级别而不是一种
当然上面说的隔离级别是MySQL的，oracle不一定全有这四种

Mysql两个搜索引擎的锁

MyISAM是表级锁

不要以为是表级锁就认为在操作时不允许再让别的进程进行操作

MySql表级锁有两种模式：

1. 表共享锁(Table Read Lock)
2. 表独占写锁(Table Write Lock)

看这两个锁的英文其实大家也都懂了，和大部分的读写锁差不多，对于读操作允许多个读操作一起进行，但是不能有写操作，在有写操作时不能有多余的读操作和写操作，
所以可见，MyISAM表的读操作不会阻塞其他用户对同一个表的读请求，但会阻塞对同一个表的写请求，读和写属于串行，写和写也是串行，读和读是并行。
如何加表锁
在执行查询语句(select)之前会自动添加读锁
在执行修改，插入，删除之前会自动添加写锁
知道什么是重点了吧，是“自动”，不用自己操作，
当然也可以显示加锁，一般是为了模拟事务操作，实现实现对某一时间点多个表的一致性读取。例如，有一个订单表orders，其中记录有订单的总金额total，同时还有一个订单明细表order_detail，其中记录有订单每一产品的金额小计subtotal，假设我们需要检查这两个表的金额合计是否相等，可能就需要执行如下两条SQL：

SELECT SUM(total) FROM orders;
SELECT SUM(subtotal) FROM order_detail;

有可能在查第二条语句时数据发生变化了，这样就有可能产生错误的结果，所以可以这样

LOCK tables orders read local,order_detail read local;
SELECT SUM(total) FROM orders;
SELECT SUM(subtotal) FROM order_detail;
Unlock tables;

显示加锁，需要说明的一点 Lock tables后加了local选项，这个就是一开始说的那个警示，

1. 其作用就是在满足MyISAM表并发插入条件的情况下，允许其他用户在表尾插入记录
2. 在用LOCKTABLES给表显式加表锁是时，必须同时取得所有涉及表的锁，并且MySQL支持锁升级。也就是说，在执行LOCK TABLES后，只能访问显式加锁的这些表，不能访问未加锁的表；同时，如果加的是读锁，那么只能执行查询操作，而不能执行更新操作。其实，在自动加锁的情况下也基本如此，MySQL问题一次获得SQL语句所需要的全部锁。这也正是MyISAM表不会出现死锁（Deadlock Free）的原因

也支持并发锁
并发锁

在一定条件下，MyISAM也支持查询和操作的并发进行。
MyISAM存储引擎有一个系统变量concurrent_insert，专门用以控制其并发插入的行为，其值分别可以为0、1或2。

1. 当concurrent_insert设置为0时，不允许并发插入
2. 当concurrent_insert设置为1时，如果MyISAM允许在一个读表的同时，另一个进程从表尾插入记录。这也是MySQL的默认设置。
3. 当concurrent_insert设置为2时，无论MyISAM表中有没有空洞，都允许在表尾插入记录，都允许在表尾并发插入记录

可以利用MyISAM存储引擎的并发插入特性，来解决应用中对同一表查询和插入锁争用。例如，将concurrent_insert系统变量为2，总是允许并发插入；同时，通过定期在系统空闲时段执行OPTIONMIZE TABLE语句来整理空间碎片，收到因删除记录而产生的中间空洞。
MyISAM的锁调度

前面讲过，MyISAM存储引擎的读和写锁是互斥，读操作是串行的。那么，一个进程请求某个MyISAM表的读锁，同时另一个进程也请求同一表的写锁，MySQL如何处理呢？答案是写进程先获得锁。不仅如此，即使读进程先请求先到锁等待队列，写请求后到，写锁也会插到读请求之前！这是因为MySQL认为写请求一般比读请求重要。这也正是MyISAM表不太适合于有大量更新操作和查询操作应用的原因，因为，大量的更新操作会造成查询操作很难获得读锁，从而可能永远阻塞。这种情况有时可能会变得非常糟糕！幸好我们可以通过一些设置来调节MyISAM的调度行为。

• 通过指定启动参数low-priority-updates，使MyISAM引擎默认给予读请求以优先的权利。
• 通过执行命令SET LOW_PRIORITY_UPDATES=1，使该连接发出的更新请求优先级降低。
• 通过指定INSERT、UPDATE、DELETE语句的LOW_PRIORITY属性，降低该语句的优先级

虽然上面3种方法都是要么更新优先，要么查询优先的方法，但还是可以用其来解决查询相对重要的应用（如用户登录系统）中，读锁等待严重的问题。
另外，MySQL也提供了一种折中的办法来调节读写冲突，即给系统参数max_write_lock_count设置一个合适的值，当一个表的读锁达到这个值后，MySQL变暂时将写请求的优先级降低，给读进程一定获得锁的机会。

InnoDb锁是行级锁

这也是，不要以为是行级锁以为只是锁行，它也能锁表

先来重点：
InnoDB行锁是通过索引上的索引项来实现的，这一点ＭySQL与Oracle不同，后者是通过在数据中对相应数据行加锁来实现的。InnoDB这种行锁实现特点意味者：只有通过索引条件检索数据****，InnoDB才会使用行级锁，否则 ，InnoDB将使用表锁！
在实际应用中，要特别注意InnoDB行锁的这一特性，不然的话，可能导致大量的锁冲突，从而影响并发性能。
上面的一定要多看几遍，没有索引项是启动不了行级锁的，它会启动表锁
InnoDb有两种类型

1. 共享锁(s):允许一个事务去读一行，阻止其他事务获得相同数据集的排他锁。
   2.排他锁(x) 允许获取排他锁的事务更新数据，阻止其他事务取得相同的数据集共享读锁和排他写锁

这两个锁很像读锁和写锁，可以这么理解
另外，为了允许行锁和表锁共存，实现多粒度锁机制，InnoDB还有两种内部使用的意向锁（Intention Locks），这两种意向锁都是表锁。

1. 意向共享锁(IS):事务打算给数据行共享锁，事务在给一个数据行加共享锁前必须先取得该表的IS锁
2. 意向排他锁(IX):事务打算给数据行加排他锁，事务在给一个数据行加排他锁前必须先取得该表的IX锁

这个很像MyISAM的表共享表锁和表独占写锁

当前锁模式/是否兼容/请求锁模式	x	IX	S	IS
X	冲突	冲突	冲突	冲突
IX	冲突	兼容	冲突	兼容
S	冲突	冲突	兼容	兼容
IS	冲突	兼容	兼容	兼容

如果一个事务请求的锁模式与当前的锁兼容，InnoDB就请求的锁授予该事务；反之，如果两者两者不兼容，该事务就要等待锁释放。
重点： 意向锁是InnoDB自动加的，不需用户干预。

• 对于UPDATE、DELETE和INSERT语句，InnoDB会自动给涉及及数据集加排他锁（Ｘ）；
• 对于普通SELECT语句，InnoDB不会任何锁

事务可以通过以下语句显示给记录集加共享锁或排锁。

1. 共享锁（Ｓ）：SELECT * FROM table_name WHERE … LOCK IN SHARE MODE
2. 排他锁（X）：SELECT * FROM table_name WHERE … FOR UPDATE
   用SELECT … IN SHARE MODE获得共享锁，主要用在需要数据依存关系时确认某行记录是否存在，并确保没有人对这个记录进行UPDATE或者DELETE操作。但是如果当前事务也需要对该记录进行更新操作，则很有可能造成死锁，对于锁定行记录后需要进行更新操作的应用，应该使用SELECT … FOR UPDATE方式获取排他锁。

说明 加共享锁是用 lock in share mode ,纯粹的select 是不拿锁的,查询是用 一致性非锁定读 来处理.

间隙锁

当我们用范围条件而不是相等条件检索数## 标题据，并请求共享或排他锁时，InnoDB会给符合条件的已有数据的索引项加锁；对于键值在条件范围内但并不存在的记录，叫做“间隙(GAP)”，InnoDB也会对这个“间隙”加锁，这种锁机制不是所谓的间隙锁（ Next-Key锁）。
举例来说，假如emp表中只有101条记录，其empid的值分别是1,2,…,100,101，下面的SQL：
SELECT * FROM emp WHERE empid > 100 FOR UPDATE
是一个范围条件的检索，InnoDB不仅会对符合条件的empid值为101的记录加锁，也会对empid大于101（这些记录并不存在）的“间隙”加锁。
InnoDB使用间隙锁的目的，一方面是为了防止幻读，以满足相关隔离级别的要求，对于上面的例子，要是不使用间隙锁，如果其他事务插入了empid大于100的任何记录，那么本事务如果再次执行上述语句，就会发生幻读；另一方面，是为了满足其恢复和复制的需要。有关其恢复和复制对机制的影响，以及不同隔离级别下InnoDB使用间隙锁的情况。
很显然，在使用范围条件检索并锁定记录时，InnoDB这种加锁机制会阻塞符合条件范围内键值的并发插入，这往往会造成严重的锁等待。因此，在实际开发中，尤其是并发插入比较多的应用，我们要尽量优化业务逻辑，尽量使用相等条件来访问更新数据，避免使用范围条件。

什么时候用行锁，什么时候用表锁

是不是很矛盾，上文说InnoDb可以用表级锁，但是我们知道InnoDb是行级锁的引擎
那就仔细看下文吧

对于InnoDb表，在绝大部分情况下都应该使用行级锁，因为事务和行锁往往是我们选择InnoDb表的理由，要不为什么不使用MyISAM表呢，但是凡事都有例外，有时候InnoDb表也需要用到表级锁

1. 第一种情况是：事务需要更新大部分或全部数据，表又比较大，如果使用默认的行锁，不仅这个事务执行效率低，而且可能造成其他事务长时间锁等待和锁冲突，这种情况下可以考虑使用表锁来提高该事务的执行速度。
2. 第二种情况是：事务涉及多个表，比较复杂，很可能引起死锁，造成大量事务回滚。这种情况也可以考虑一次性锁定事务涉及的表，从而避免死锁、减少数据库因事务回滚带来的开销。

需要说明的是

1. 使用LOCK TALBES虽然可以给InnoDB加表级锁，但是表锁不是由InnoDb引擎层管理的，而是由上一层MySQL Server负责的，仅当autocommit=0、innodb_table_lock=1（默认设置）时，InnoDB层才能知道MySQL加的表锁，ＭySQL Server才能感知InnoDB加的行锁，这种情况下，InnoDB才能自动识别涉及表级锁的死锁；否则，InnoDB将无法自动检测并处理这种死锁。
2. 在用LOCAK TABLES对InnoDB锁时要注意，要将AUTOCOMMIT设为0，否则ＭySQL不会给表加锁；事务结束前，不要用UNLOCAK TABLES释放表锁，因为UNLOCK TABLES会隐含地提交事务；COMMIT或ROLLBACK产不能释放用LOCAK TABLES加的表级锁，必须用UNLOCK TABLES释放表锁，正确的方式见如下语句。

例如，如果需要写表t1并从表t读，可以按如下做：

SET AUTOCOMMIT=0;
LOCAK TABLES t1 WRITE, t2 READ, ...;
[do something with tables t1 and here];
COMMIT;
UNLOCK TABLES;

关于死锁

因为MyISAM是表锁，一次性获得所需的全部锁，要不全满足，要不等待，所以是不会出现死锁的，但是在InnoDb中，除单个SQL组成的事务外，锁是逐步获得的，这就决定了InnoDb发生死锁是可能的

如果不知道死锁是什么意思，那请百度

发生死锁后，InnoDB一般都能自动检测到，并使一个事务释放锁并退回，另一个事务获得锁，继续完成事务。
但在涉及外部锁，或涉及锁的情况下， InnoDB并不能完全自动检测到死锁， 这需要通过设置锁等待超时参数innodb_lock_wait_timeout来解决。需要说明的是，这个参数并不是只用来解决死锁问题，在并发访问比较高的情况下，
如果大量事务因无法立即获取所需的锁而挂起，会占用大量计算机资源，造成严重性能问题，甚至拖垮数据库。我们通过设置合适的锁等待超时阈值，可以避免这种情况发生。

通常来说，死锁都是应用设计的问题，通过调整业务流程、数据库对象设计，事务大小，以及访问数据库的SQL语句，绝大部分都是可以避免的，下面就介绍几种死锁的常用方法

1. 在应用中，如果不同的程序会并发存取多个表，应尽量约定以相同的顺序为访问表，这样可以大大降低产生死锁的机会。如果两个session访问两个表的顺序不同，发生死锁的机会就非常高！但如果以相同的顺序来访问，死锁就可能避免。
2. 在程序以批量方式处理数据的时候，如果事先对数据排序，保证每个线程按固定的顺序来处理记录，也可以大大降低死锁的可能
3. 在事务中，如果要更新记录，应该直接申请足够级别的锁，即排他锁，而不应该先申请共享锁，更新时再申请排他锁，甚至死锁。
4. 在REPEATEABLE-READ(可重复读)隔离级别下，如果两个线程同时对相同条件记录用SELECT…ROR UPDATE加排他锁，在没有符合该记录情况下，两个线程都会加锁成功。程序发现记录尚不存在，就试图插入一条新记录，如果两个线程都这么做，就会出现死锁。这种情况下，将隔离级别改成READ COMMITTED(以提交读)，就可以避免问题
5. 当隔离级别为READ COMMITED时，如果两个线程都先执行SELECT…FOR UPDATE，判断是否存在符合条件的记录，如果没有，就插入记录。此时，只有一个线程能插入成功，另一个线程会出现锁等待，当第１个线程提交后，第２个线程会因主键重出错，但虽然这个线程出错了，却会获得一个排他锁！这时如果有第３个线程又来申请排他锁，也会出现死锁。对于这种情况，可以直接做插入操作，然后再捕获主键重异常，或者在遇到主键重错误时，总是执行ROLLBACK释放获得的排他锁。

尽管通过上面的设计和优化等措施，可以大减少死锁，但死锁很难完全避免。因此，在程序设计中总是捕获并处理死锁异常是一个很好的编程习惯。
如果出现死锁，可以用SHOW INNODB STATUS命令来确定最后一个死锁产生的原因和改进措施。

总结

对于ＭyISAM的表锁，主要有以下几点
（１）共享读锁（S）之间是兼容的，但共享读锁（S）和排他写锁（X）之间，以及排他写锁之间（X）是互斥的，也就是说读和写是串行的。
（２）在一定条件下，ＭyISAM允许查询和插入并发执行，我们可以利用这一点来解决应用中对同一表和插入的锁争用问题。
（３）ＭyISAM默认的锁调度机制是写优先，这并不一定适合所有应用，用户可以通过设置LOW_PRIPORITY_UPDATES参数，或在INSERT、UPDATE、DELETE语句中指定LOW_PRIORITY选项来调节读写锁的争用。
（４）由于表锁的锁定粒度大，读写之间又是串行的，因此，如果更新操作较多，ＭyISAM表可能会出现严重的锁等待，可以考虑采用InnoDB表来减少锁冲突。
对于InnoDB表，主要有以下几点
（１）InnoDB的行销是基于索引实现的，如果不通过索引访问数据，InnoDB会使用表锁。
（２）InnoDB间隙锁机制，以及InnoDB使用间隙锁的原因。
（３）在不同的隔离级别下，InnoDB的锁机制和一致性读策略不同。
（４）ＭySQL的恢复和复制对InnoDB锁机制和一致性读策略也有较大影响。
（５）锁冲突甚至死锁很难完全避免。

在了解InnoDB的锁特性后，用户可以通过设计和SQL调整等措施减少锁冲突和死锁，包括：

• 尽量使用较低的隔离级别
• 精心设计索引，并尽量使用索引访问数据，使加锁更精确，从而减少锁冲突的机会。
• 选择合理的事务大小，小事务发生锁冲突的几率也更小。
• 给记录集显示加锁时，最好一次性请求足够级别的锁。比如要修改数据的话，最好直接申请排他锁，而不是先申请共享锁，修改时再请求排他锁，这样容易产生死锁。
• 不同的程序访问一组表时，应尽量约定以相同的顺序访问各表，对一个表而言，尽可能以固定的顺序存取表中的行。这样可以大减少死锁的机会。
• 尽量用相等条件访问数据，这样可以避免间隙锁对并发插入的影响。
• 不要申请超过实际需要的锁级别；除非必须，查询时不要显示加锁。
• 对于一些特定的事务，可以使用表锁来提高处理速度或减少死锁的可能。