目录
- MySQL 8.0相对于5.7的复制改进，都有哪些呢？
- 跑truncate table，4亿条数据会不会造成长时间锁表呢?有什么更好的方法吗?
- 明明有个索引“感觉”应该被选中，EXPLAIN时在possible_keys也有它，但最后没被选中，可能的原因有哪些？
- 主从复制线程均正常（为Yes，也没报错），Master的binlog已到binlog.000100，但slave上看到Master_Log_File却只到binlog.000090，可能的原因有哪些?
一、MySQL 8.0相对于5.7的复制改进，都有哪些呢？
宋利兵老师：《MySQL 8.0相对于5.7的复制改进》的公开课也讨论了这个命题，简单概括主要有两部分：
（一）普通复制功能改进
1、新增WRITESET并行复制模式，提高并行度，降低延迟
2、在多源复制中，可在线动态修改每个channel的filter rule，并且能在P_S中查看/监控
3、Binary Log中存储更多元数据，并支持毫秒级别的延迟监控
4、对JSON Documents的复制效率更高了
5、支持DDL Crashsafe
6、增加caching_sha2_password安全策略，提高复制安全性
（二）MGR功能改进:
1.支持设置节点权重，且权重最大的在线节点将被选举为主
2.每个节点中存储更多的状态信息，如版本、角色等
3.可根据从节点的事务状态，自动化流控
4.离开集群的服务器自动被设置为read only，避免被误操作更新数据
5.可监控MGR的内存使用情况
二、跑truncate table，4亿条数据会不会造成长时间锁表呢?有什么更好的方法吗?
最好是create新表，然后交叉rename对调，再drop/truncate table或其他方式清除数据。
（一）可操作步骤：
1、创建新的 tmp 表，正式表与tmp表表名交换（注意在一个SQL里完成，并锁表）
2、对 tmp 表创建硬链接 ln tmp.ibd tmp.ibd.hdlk
3、mysql中删除表tmp（truncate / drop 都行）
4、然后找个业务不繁忙的时间删除数据文件或者用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
三、明明有个索引“感觉”应该被选中，EXPLAIN时在possible_keys也有它，但最后没被选中，可能的原因有哪些？
（一）执行计划如下：
desc select * from t1 where c2 >= 2;
key: NULL
key_len: NULL
rows: 14
filtered: 92.86
Extra: Using where(二)可能的原因如下：
1、隐式转换
2、表碎片，因为表的碎片率过高
3、根据索引读取到的数据在整个表中的数据占比超过30%
4、统计信息没有及时更新
（三）上述执行计划的结果是：
预计扫描的行数为14行，filtered（是指返回结果的行占需要读到的行的百分比）的值为92%。
当前执行计划中filtered值92% 说明根据索引查询获取的结果占整张表的92%，在MySQL中根据索引查询的结果占整张表的数据30%则不会走索，所以不会走索引。
另外，也有可能是表的碎片率过高或隐式转换导致的。
四、主从复制线程均正常（为Yes，也没报错），Master的binlog已到binlog.000100，但slave上看到Master_Log_File却只到binlog.000090，可能的原因有哪些?
首先要注意，这是Master_Log_File IO线程延迟，并不是Relay_Master_Log_File SQL线程延迟。
（一）可能的原因如下：
1、由于sync_relay_log值过低，导致Slave频繁刷新relay_log文件，使 Slave的硬盘资源消耗过高，所以导致SlaveIO Thread很慢。
2、Master/Slave压力过大导致Slave IO Thread不能及时响应， 无法及时获得Master的event。
3、网络丢包严重。小包可以连接并且保持连接不断，但是大包就无法发送。可能是Master和Slave关于TCP MTU值设置不一致导致。
4、Master和Slave网络链接已经断开。但slave_net_timeout值等于0（表示完全禁用心跳）或者slave_net_timeout和Slave_heartbeat_period非常大（表示检测主从心跳的时间）。
5、Master的binlog非常大，io线程的file很长时间都在读同一个。
(二)总结
本次案例是在主库进行压力测试，在压力测试的过程中，因为Master本身的压力就很大Master来不及把binlog发送给Slave。所以表面上看起来没有延迟，但实际上已经产生了延迟。
公众号：知数堂，更多MySQL干货知识，关注公众号获取。
