quanzhan_King的博客

在8.0中 hash scan 使用一个std::unordered_multimap的hash容器，记录其key - value值，每个key - value 代表修改的一行值，因为multimap容器允许重复的key - value，因此可以存在相同的行记录，这和5.7的实现不同，5.7是自己写的，而8.0 用的容器。其中key为当前表中根据每个字段计算出来的crc32值，句函数为Hash_slave_rows::make_hash_key，也就是checksum_crc32函数。

大家应该都在各种电商网站检索过商品，检索商品一般都是通过什么实现呢？搜索引擎Elasticsearch。那么问题来了，商品上架，数据一般写入到MySQL的数据库中，那么用于检索的数据又是怎么同步到Elasticsearch的呢？MySQL同步ES。

数据库编译器产生执行计划，决定着SQL的实际执行方式。但是编译器只是尽力服务，所有数据库的编译器都不是尽善尽美的。上述提到的多数场景，在其它数据库中也存在性能问题。了解数据库编译器的特性，才能避规其短处，写出高性能的SQL语句。程序员在设计数据模型以及编写SQL语句时，要把算法的思想或意识带进来。编写复杂SQL语句要养成使用 WITH 语句的习惯。简洁且思路清晰的SQL语句也能减小数据库的负担。

通常一旦连接建立，MySQLD端的线程会堵塞在poll上，而poll的就是连接socket的fd，等待读取命令，也就是读取MySQL net packet的header。net_read_raw_loop会循环读取需要的字节数量，而MySQL net packet就是4个字节，一旦poll检测到数据达到，则会从vio_socket_io_wait中return 0，然后调用mysql_socket_recv从socketfd中读取数据。这个时候因为没有读取到预期的4字节，那么就会进入判定流程，如果不是。

1 Extra中的为Using index的情况查询列被索引覆盖&&where筛选条件是一个基于索引前导列的查询，意味着 通过索引查找就能直接找到符合条件的数据，并且无须回表2 Extra中的为空的情况查询列未被索引覆盖&&where筛选列是索引的前导列，意味着通过索引查找并且通过回表来找到未被索引覆盖的字段，3 Extra中的为Using where;使用了索引： 要考虑索引扫描+回表表扫描的代价。4 Extra中的为Using where;

1、 sql优化1.1 SQL 语句简化，简化是 SQL 优化的一大利器，因为简单，所以优越。1.2 尽可能避免或者杜绝多表复杂关联，大表关联是大表处理的噩梦，一旦打开了这个口子，越来越多的需求需要关联，性能优化就没有回头路了1.4 SQL 中尽可能避免反连接，避免半连接，这是优化器做得薄弱的一方面，什么是反连接，半连接？其实比较好理解，举个例子：not in，not exists 就是反连接，in，exists 就是半连接，在千万级大表中出现这种问题，性能是几个数量级的差异。1.3 多表关联时

1. mysql锁介绍表锁：锁住整张表表级别的锁定是MySQL各存储引擎中最大颗粒度的锁定机制。该锁定机制最大的特点是实现逻辑非常简单，带来的系统负面影响最小。所以获取锁和释放锁的速度很快。由于表级锁一次会将整个表锁定，所以可以很好的避免困扰我们的死锁问题。当然，锁定颗粒度大所带来最大的负面影响就是出现锁定资源争用的概率也会最高，致使并大度大打折扣。行锁：锁住一行或者多行如果数据库表没有加索引，那么更新操作的时候会锁住整张表，也就是所谓的表级锁；如果有索引，并且查询条件中也带有这些字段，那么就会

1、索引优化1.1 建表或加索引时，保证表里互相不存在冗余索引。对于MySQL来说，如果表里已经存在key(a,b)，则key(a)为冗余索引，需要删除。1.2 复合索建立索引时，多考虑建立复合索引，并把区分度最高的字段放在最前面。比如 select * from goods where goods_no = 'aaa' and state=1;这种情况我们只需要建了一个复合索引就可以，这就相当于创建了(goods_no ,state)、(goods_no )两个索引，这就是最佳左前缀特性。

这个BUG比较老了，主要是5.7.17以下的版本可能会遇到。这个BUG主要是主库ACK receiver线程需要将半同步从库的连接的fd注册到其中，然后监控连接的fd是否有数据到达，其实就是ACK 信息，如果有ACK信息到达，则需要读取信息同时解析ACK包，然后决定唤醒哪个或者哪些事务。但是这里使用的是select 函数，其原型如下，其中第一个参数nfds有如下限制（来自 linux man page）也就是说如果当前进程打开的文件描述符大于了1023，使用select会触发这个问题，那么回到M

1. 为什么不用 UUID经过上篇文章的介绍，我们知道在 MySQL 中，主键索引就是聚簇索引，MySQL 表中的数据是根据主键值聚集在一起的，聚簇索引是一棵 B+Tree，这棵树中的数据是有序的。所以，如果我们使用 UUID 字符串作为主键，那么就会导致每次数据插入的时候，都需要在 B+Tree 中寻找到适合它自己的位置，找到之后就有可能要挪动后面的节点（就像在数组中插入一条记录），挪动后面的节点，就有可能涉及到页分裂，插入效率就会降低。另一方面，在非聚簇索引中，叶子结点保存的

1. 什么是聚簇索引数据库的索引从不同的角度可以划分成不同的类型，聚簇索引便是其中一种。聚簇索引英文是 Clustered Index，有时候小伙伴们可能也会看到有人将之称为聚集索引等，与之相对的是非聚簇索引或者二级索引。聚簇索引并不是一种单独的索引类型，而是一种数据的存储方式。在 MySQL 的 InnoDB 存储引擎中，所谓的聚簇索引实际上就是在同一个 B+Tree 中保存了索引和数据行：此时，数据放在叶子结点中，聚簇聚簇，意思就是说数据行和对应的键值紧凑的存在一起。

1. 什么是索引说到索引，最常见的例子就是查字典，当我们需要查询某一个字的含义时，正常操作都是先根据字典的索引，找到该字在哪一页，然后直接翻到该页就行了。如果没有这个索引的话，那么我们就得一页一页的翻字典，直到找到该字。很明显，相对于第一种方案，第二种方案效率就要低很多了。数据库中的索引也是类似的。索引，我们也称之为 index 或者 key，当数据量比较少的时候，索引对于查询产生的效果并不明显，所以索引常常被人所忽略，但是当数据量比较大的时候，一个优秀的索引对查询产生的影响就是非常明显的了。在我

一、问题说明和模拟方式就是主从一个表，主库大约600M，从库大约900M，当然主从的环境肯定是一致的，但是从库的并发比较高MTS使用了16个 worker线程，从并发来看基本都在使用。我模拟的方法也很简单，无非就是主库开启writeset，将参binlog_transaction_dependency_history_size调大，这样能够保证last commit尽可能降低，如下：