RuaaaHaHa的博客

在数据库中，查询语句的执行流程通常包括连接器、分析器、优化器、执行器等模块，最终到达存储引擎。然而，当我们谈论更新语句的执行流程时，情况会有所不同。更新操作不仅涉及数据的读取，还包括数据的修改和写入，这一过程更为复杂。本文将探讨更新语句的执行流程，并揭示MySQL实现数据恢复的奥秘。通过了解这些底层原理，我们不仅能更好地理解数据库的工作机制，还能在实际应用中更加得心应手。首先，查询语句会走的流程，更新语句也同样会走一遍，所以先回顾一下SQL语句基本的执行链路。执行语句要先连接数据库，这是连接器的工作。

优化器选择索引的目的，是找到一个最优的执行方案，并用最小的代价去执行语句。如果使用索引 b 进行查询，那么就是扫描索引 b 的最后 50001 个值，与上面的执行过程相同，也是需要回到主键索引上取值再判断，所以需要扫描 50001 行。采样统计的时候，InnoDB 默认会选择 N 个数据页，统计这些页面上的不同值，得到一个平均值，然后乘以这个索引的页面数，就得到了这个索引的基数。MySQL是通过采样统计来得到索引的基数的，虽然把整张表一行行统计，可以得到精确的结果，但是代价太高了，索引选择了采样统计。

今天的话题是，在不同的业务场景下，应该选择普通索引，还是唯一索引假设现在维护一个市民系统，每个人都有一个唯一的身份证号，而且业务代码已经保证了写入两个重复的身份证号。如果市民系统需要按照身份证号查姓名，就会执行类似下面的sql语句;这种情况下，会考虑在id_card字段上建索引。由于身份证号字段比较大，不建议作为主键，那么现在就有了两个选择，要么给id_card字段创建唯一索引，要么创建一个普通索引。如果业务代码已经保证不会写入重复的身份证号，那么这两个选择逻辑上都是正确的。

如果是可重复读隔离级别，事务T启动的时候会创建一个视图read-view，之后事务T执行期间，即使有其他事务修改了数据，事务T看到的仍然跟在启动时看到的一样。但当一个事务要更新一行的时候，如果刚好有另外一个事务拥有这一行的行锁，这个事务会被锁住，进入等待状态。问题是，既然进入了等待状态，那么等到这个事务自己获取到行锁要更新数据的时候，它读到的值又是什么呢？

但是第二种策略也是有额外负担的，可以想象一下这个过程：每当一个事务被锁的时候，就要看看它所依赖的线程有没有被别人锁住，如此循环，最后判断是否出现了循环等待，也就是死锁。但是这种操作本身带有一定的风险，因为业务设计的时候一般不会把死锁当做一个严重错误，毕竟出现死锁了，就回滚，然后通过业务重试一般就没问题了，这是业务无损的。当然，为了保证交易的原子性，要把这三个操作放在一个事务中。对于第一种策略，设置时间太长对于在线服务是无法容忍的，太短，又可能误伤类似锁等待的情况，所以，正常情况下，使用第二种策略。

全局锁的典型使用场景是，

索引的出现其实就是为了提高数据查询的效率，就像书的目录一样。一本500页的书，如果你想快速找到其中的某一个知识点，在不借助目录的情况下，那寻找起来是很费劲的。同样，对于数据库的表而言，索引其实就是它的“目录”。

当前值是 D，但是在查询这条记录的时候，不同时刻启动的事务会有不同的 readview。如图中看到的，在视图 1、2、3 里面，这一个记录的值分别是 A、B、D，同一条记录在系统中可以存在多个版本，就是数据库的多版本并发控制（MVCC）。同时你会发现，即使现在有另外一个事务正在将 D 改成 E，这个事务跟 readview 1、2、3 对应的事务是不会冲突的。到了月底你要做数据校对，也就是判断上个月的余额和当前余额的差额，是否与本月的账单明细一致。记录上的最新值，通过回滚操作，都可以得到前一个状态的值。