明明有个索引“感受”应该被选中，EXPLAIN时在possible_keys也有它，但最后没被选中，可能的缘由有哪些？

目录

• MySQL 8.0相对于5.7的复制改进，都有哪些呢？
• 跑truncate table，4亿条数据会不会形成长时间锁表呢?有什么更好的方法吗?
• 明明有个索引“感受”应该被选中，EXPLAIN时在possible_keys也有它，但最后没被选中，可能的缘由有哪些？
• 主从复制线程均正常（为Yes，也没报错），Master的binlog已到binlog.000100，但slave上看到Master_Log_File却只到binlog.000090，可能的缘由有哪些?

---

1、MySQL 8.0相对于5.7的复制改进，都有哪些呢？

宋利兵老师：《MySQL 8.0相对于5.7的复制改进》的公开课也讨论了这个命题，简单归纳主要有两部分：

（一）普通复制功能改进

一、新增WRITESET并行复制模式，提升并行度，下降延迟

二、在多源复制中，可在线动态修改每一个channel的filter rule，而且能在P_S中查看/监控

三、Binary Log中存储更多元数据，并支持毫秒级别的延迟监控

四、对JSON Documents的复制效率更高了

五、支持DDL Crashsafe

六、增长caching_sha2_password安全策略，提升复制安全性

（二）MGR功能改进:

1.支持设置节点权重，且权重最大的在线节点将被选举为主

2.每一个节点中存储更多的状态信息，如版本、角色等

3.可根据从节点的事务状态，自动化流控

4.离开集群的服务器自动被设置为read only，避免被误操做更新数据

5.可监控MGR的内存使用状况

2、跑truncate table，4亿条数据会不会形成长时间锁表呢?有什么更好的方法吗?

最好是create新表，而后交叉rename对调，再drop/truncate table或其余方式清除数据。

（一）可操做步骤：

一、建立新的 tmp 表，正式表与tmp表表名交换（注意在一个SQL里完成，并锁表）

二、对 tmp 表建立硬连接 ln tmp.ibd tmp.ibd.hdlk

三、mysql中删除表tmp（truncate / drop 都行）

四、而后找个业务不繁忙的时间删除数据文件或者用coreutils 的truncate慢慢搞

（二）关于truncate table，官档解释：

Logically, TRUNCATE TABLE is similar to a DELETE statement that deletes all rows, or a sequence of DROP TABLE and CREATE TABLE statements
When a table is truncated, it is dropped and re-created in a new .ibd file, and the freed space is returned to the operating system

3、明明有个索引“感受”应该被选中，EXPLAIN时在possible_keys也有它，但最后没被选中，可能的缘由有哪些？
（一）执行计划以下：

desc select * from t1 where c2 >= 2; 
key: NULL 
key_len: NULL 
rows: 14 
filtered: 92.86 
Extra: Using where

(二)可能的缘由以下：

一、隐式转换

二、表碎片，由于表的碎片率太高

三、根据索引读取到的数据在整个表中的数据占比超过30%

四、统计信息没有及时更新

（三）上述执行计划的结果是：

预计扫描的行数为14行，filtered（是指返回结果的行占须要读到的行的百分比）的值为92%。

当前执行计划中filtered值92% 说明根据索引查询获取的结果占整张表的92%，在MySQL中根据索引查询的结果占整张表的数据30%则不会走索，因此不会走索引。
另外，也有多是表的碎片率太高或隐式转换致使的。

4、主从复制线程均正常（为Yes，也没报错），Master的binlog已到binlog.000100，但slave上看到Master_Log_File却只到binlog.000090，可能的缘由有哪些?

首先要注意，这是Master_Log_File IO线程延迟，并非Relay_Master_Log_File SQL线程延迟。

（一）可能的缘由以下：

一、因为sync_relay_log值太低，致使Slave频繁刷新relay_log文件，使 Slave的硬盘资源消耗太高，因此致使SlaveIO Thread很慢。

二、Master/Slave压力过大致使Slave IO Thread不能及时响应， 没法及时得到Master的event。

三、网络丢包严重。小包能够链接而且保持链接不断，可是大包就没法发送。多是Master和Slave关于TCP MTU值设置不一致致使。

四、Master和Slave网络连接已经断开。但slave_net_timeout值等于0（表示彻底禁用心跳）或者slave_net_timeout和Slave_heartbeat_period很是大（表示检测主从心跳的时间）。

五、Master的binlog很是大，io线程的file很长时间都在读同一个。

(二)总结

本次案例是在主库进行压力测试，在压力测试的过程当中，由于Master自己的压力就很大Master来不及把binlog发送给Slave。因此表面上看起来没有延迟，但实际上已经产生了延迟。

---

公众号：知数堂，更多MySQL干货知识，关注公众号获取。

原文连接：https://zhishutang.com/dp8

推荐阅读：https://zhishutang.com/xdI