蘑菇蘑菇不会开花的专栏

在实际项目开发中，我们经常将 MySQL 作为业务数据库，ES 作为查询数据库，用来实现读写分离，缓解 MySQL 数据库的查询压力，应对海量数据的复杂查询。这其中有一个很重要的问题，就是如何实现 MySQL 数据库和 ES 的数据同步，今天和大家聊聊 MySQL 和 ES 数据同步的各种方案。我们先看看下面 4 种常用的数据同步方案。

所谓 MySQL 主从，就是建立两个完全一样的数据库，一个是主库，一个是从库，主库对外提供读写的操作，从库对外提供读的操作。

本来是一个平静而美好的下午，其他部门的同事要一份数据报表临时汇报使用，因为系统目前没有这个维度的功能，所以需要写个SQL马上出一下，一个同事接到这个任务，于是开始在测试环境拼装这条 SQL，刚过了几分钟，同事已经自信的写好了这条SQL，于是拿给DBA，到线上跑一下，用客户端工具导出Excel 就好了，毕竟是临时方案嘛。就在SQL执行了之后，意外发生了，先是等了一下，发现还没执行成功，猜测可能是数据量大的原因，但是随着时间滴滴答答流逝，逐渐意识到情况不对了，一看监控，

我们使用mysql时，使用xx!='aa'这种条件为什么无法筛选出值为NULL的字段呢。是的，MySQL 中null 值确实无法通过这种条件筛选出来，因为 null 值的定义就跟普通值不一样。第一条 SQL 表达的意思是：不知道这个人的手机号码，。第二条 SQL 表达的意思是：这个人就是。按照这个角度去看待群里同学的提问，其实不难理解为什么 xx!=‘xx’ 查询不出 null 的数据了。因为 null 值表示未知，它的值可能是任意你能想到的值，目前还不能定义它。

两者的语法区别在于，group by可以进行单列去重，group by的原理是先对结果进行分组排序，然后返回每组中的第一条数据。且是根据group by的后接字段进行去重的。如果列具有NULL值，并且对该列使用DISTINCT子句，MySQL将保留一个NULL值，并删除其它的NULL值，因为DISTINCT子句将所有NULL值视为相同的值。distinct多列的去重，则是根据指定的去重的列信息来进行，即只有所有指定的列信息都相同，才会被认为是重复的信息。的内容），我们对这两条sql进行分析，可以看到，在。

当我们对一张数据表中的记录进行统计的时候，习惯都会使用 count 函数来统计，但是 count 函数传入的参数有很多种，比如count(1)count(*)count(字段)等。到底哪种效率是最好的呢？是不是count(*)效率最差？我曾经以为count(*)是效率最差的，因为认知上会读取所有表中的字段，所以凡事带有字符的就觉得会读取表中所有的字段，当时网上有很多博客也这么说。但是，当我深入 count 函数的原理后，被啪啪啪的打脸了！

大家都知道 mysql 中数据是存储在物理磁盘上的，而真正的数据处理又是在内存中执行的。由于磁盘的读写速度非常慢，如果每次操作都对磁盘进行频繁读写的话，那么性能一定非常差。为了上述问题，InnoDB 将数据划分为若干页，以页作为磁盘与内存交互的基本单位，一般页的大小为 16KB。这样的话，一次性至少读取 1 页数据到内存中或者将 1 页数据写入磁盘。通过减少内存与磁盘的交互次数，从而提升性能。时间维度：如果一条数据正在在被使用，那么在接下来一段时间内大概率还会再被使用。

执行一条 SQL 查询语句，期间发生了什么？连接器：建立连接，管理连接、校验用户身份；查询缓存：查询语句如果命中查询缓存则直接返回，否则继续往下执行。MySQL 8.0 已删除该模块；解析 SQL，通过解析器对 SQL 查询语句进行词法分析、语法分析，然后构建语法树，方便后续模块读取表名、字段、语句类型；执行 SQL：执行 SQL 共有三个阶段：预处理阶段：检查表或字段是否存在；将 select * 中的 * 符号扩展为表上的所有列。

在 MySQL 中，虽然 MVCC 是一个非常强大的并发控制机制，但它不能完全解决幻读问题。幻读问题在不同的事务隔离级别下有不同的表现，而在可重复读隔离级别下，Next - Key 锁通过对记录和间隙的锁定，弥补了 MVCC 在防止幻读方面的不足。对于开发人员和数据库管理员来说，深入理解 MVCC 和 Next - Key 锁的工作原理，有助于在设计和管理数据库应用时，正确处理并发事务，确保数据的一致性和准确性。

这次我以 MySQL 8.0.26 版本，在可重复读隔离级别之下，做了几个实验，让大家了解了唯一索引和非唯一索引的行级锁的加锁规则。我这里总结下， MySQL 行级锁的加锁规则。当查询的记录是「存在」的，在索引树上定位到这一条记录后，将该记录的索引中的 next-key lock 会退化成「记录锁」。当查询的记录是「不存在」的，在索引树找到第一条大于该查询记录的记录后，将该记录的索引中的 next-key lock 会退化成「间隙锁」。

全称Multi-Version Concurrency Control，即多版本并发控制，主要是为了提高数据库的并发性能。以下文章都是围绕InnoDB引擎来讲，因为myIsam不支持事务。同一行数据平时发生读写请求时，会上锁阻塞住。但mvcc用更好的方式去处理读—写请求，做到在发生快照读—写请求冲突时不用加锁。这个读是指的快照读，而不是当前读，当前读是一种加锁操作，是悲观锁。其特点就是在同一时间，不同事务可以读取到不同版本的数据，从而去解决脏读和不可重复读的问题。

我的钱包，共有 100 元。今天我心情好，我决定给你的转账99元，最后的结果肯定是我的余额变为 1元，你的余额多了99元。可以看到这个转账的过程涉及到了两次修改数据库的操作。假设在执行第三步骤之后，服务器忽然掉电了，就会发生一个蛋疼的事情，我的账户扣了 99元，但是钱并没有到你的账户上，也就是说这 99元消失了！要解决这个问题，就要保证转账业务里的所有数据库的操作是不可分割的，要么全部执行成功 ，要么全部失败，不允许出现中间状态的数据。

当事务 A 还没提交的时候，事务 B 向该表插入一条 id = 4 的新记录，这时会判断到插入的位置已经被事务 A 加了间隙锁，于是事物 B 会生成一个插入意向锁，然后将锁的状态设置为等待状态（PS：MySQL 加锁时，是先生成锁结构，然后设置锁的状态，如果锁状态是等待状态，并不是意味着事务成功获取到了锁，只有当锁状态为正常状态时，才代表事务成功获取到了锁），此时事务 B 就会发生阻塞，直到事务 A 提交了事务。这种方法只适用于支持「可重复读隔离级别的事务」的存储引擎。write）发生冲突。