m0_46392035的博客

顾名思义，行锁就是针对数据表中行记录的锁。这很好理解，比如事务 A 更新了一行，而这时候事务 B 也要更新同一行，则必须等事务 A 的操作完成后才能进行更新。在 InnoDB 事务中，行锁是在需要的时候才加上的，但并不是不需要了就立刻释放，而是要等到事务结束时才释放。这个就是两阶段锁协议。行锁容易出现死锁，需要注意，尽量减少行锁使用时间。当并发系统中不同线程出现循环资源依赖，涉及的线程都在等待别的线程释放资源时，就会导致这几个线程都进入无限等待的状态，称为死锁。这里我用数据库中的行锁举个例子。在 In

数据库锁设计的初衷是处理并发问题。作为多用户共享的资源，当出现并发访问的时候，数据库需要合理地控制资源的访问规则。而锁就是用来实现这些访问规则的重要数据结构。根据加锁的范围，MySQL 里面的锁大致可以分成全局锁、表级锁和行锁三类。这篇文章主要讲前面两类。这里需要说明的是，锁的设计比较复杂，这两篇文章不会涉及锁的具体实现细节，主要介绍的是碰到锁时的现象和其背后的原理。全局锁，可以备份数据，注意，在备份过程中整个库完全处于只读状态。但是让整库都只读，听上去就很危险：看来加全局锁不太好。但是细想一下，备份为什么

如果我执行 select * from T where k between 3 and 5，需要执行几次树的搜索操作，会扫描多少行？ 在这个过程中，回到主键索引树搜索的过程，我们称为回表。可以看到，这个查询过程读了k 索引树的 3 条记录（步骤 1、3 和 5），回表了两次（步骤 2 和 4）。在这个例子中，由于查询结果所需要的数据只在主键索引上有，所以不得不回表。那么，有没有可能经过索引优化，避免回表过程呢？------组合索引在建立联合索引的时候，如何安排索引内的字段顺序。这里我们的评估标准是，索引

索引的出现是为了提高查询效率，但是实现索引的方式却有很多种，所以这里也就引入了索引模型的概念。可以用于提高读写效率的数据结构很多，这里我先给你介绍三种常见、也比较简单的数据结构，它们分别是哈希表、有序数组和搜索树。哈希表这种结构适用于只有等值查询的场景（按值查询）有序数组在等值查询和范围查询场景中的性能就都非常优秀。（二分查找）如果仅仅看查询效率，有序数组就是最好的数据结构了。但是，在需要更新数据的时候就麻烦了，你往中间插入一个记录就必须得挪动后面所有的记录，成本太高。所以，有序数组索引只适用于静态

转账过程具体到程序里会有一系列的操作，比如查询余额、做加减法、更新余额等，这些操作必须保证是一体的，不然等程序查完之后，还没做减法之前，你这 100 块钱，完全可以借着这个时间差再查一次，然后再给另外一个朋友转账，如果银行这么整，不就乱了么？这时就要用到“事务”这个概念了。简单来说，事务就是要保证一组数据库操作，要么全部成功，要么全部失败。在 MySQL中，事务支持是在引擎层实现的。你现在知道，MySQL 是一个支持多引擎的系统，但并不是所有的引擎都支持事务。比如 MySQL 原生的 MyISA

redo日志其实就可以类比黑板的功能，记录着操作。而粉板和账本配合的整个过程，其实就是MySQL里经常说到的WAL技术，WAL的全称是Write-Ahead Logging，它的关键点就是先写日志，再写磁盘，也就是先写粉板，等不忙的时候再写账本。具体来说，当有一条记录需要更新的时候，InnoDB引擎就会先把记录写到redo log（粉板）里面，并更新内存，这个时候更新就算完成了。同时，InnoDB引擎会在适当的时候，将这个操作记录更新到磁盘里面，而这个更新往往是在系统比较空闲的时候做，这就像打烊以后掌柜做的

问题引导：基础架构：一条SQL查询语句是如何执行的？正文我们看到的只是输入一条语句，返回一个结果，却不知道这条语句在 MySQL 内部的执行过程。mysql内部又有什么样子的结构呢？大致如下图所示。1.mysql内部结构大体来说，MySQL 可以分为 Server 层和存储引擎层两部分。Server 层包括连接器、查询缓存、分析器、优化器、执行器等，涵盖 MySQL 的大多数核心服务功能，以及所有的内置函数（如日期、时间、数学和加密函数等），所有跨存储引擎的功能都在这一层实.

上面资料来源于下面这个博客，我只是挑出自己感觉比较好的出来。MyISAM与InnoDB 的区别（9个不同点）_Chackca的博客-CSDN博客_myisam和innodb的区别