2020-09-02

1, 索引失效情况

模糊查询
隐式转换
列的运算
2， explain
最左匹配原则
where 条件里面，列可以多，但是一定要把索引列放在第一个

3，主从延迟

大表加列 主库50分钟，那么从库可能也需要50分钟

大事务 一个事务，做了太多的操作，最后才提交，传到从库会很慢

大量小事务 主库并发太高，从库通过单线程同步，会追不上主库

网络： 闪断，时好时坏，断了为0，从库会认为已经追上了主库，所以主 从延迟为0，表现就是，主从延迟秒数忽大忽小

机器性能问题 ： 从库查询导致hang住，主库此时传来DDL

主库事务的持续时间大小等等

如果一个主从延迟非常长：
同时存在数据同步延时和relaybin日志堆积现象
， 以下是调查解决过程：
1、查询从库状态：show slave status \G

结果为Slave_IO_State、Master_Host、Master_User。。。等等

2、在Slave_SQL_Running_State字段内容一直为 Reading event from the relay log， 并且Seconds_Behind_Master字段值不为0， 说明从库同步存在问题。

3、在show slave status结果集中找到 Relay_Log_File和 Relay_Log_Pos字段内容：f62de755ed08-relay-bin.000005 252587725

4、跟上面字段信息，执行sql语句： show relaylog events in ‘f2fd44f1d6d9-relay-bin.000005’ limit 252587725,50 ; 结果会显示出从库执行速度慢的操作。

SHOW RELAYLOG EVENTS 语句的使用：

SHOW RELAYLOG EVENTS
[IN ‘log_name’]
[FROM pos]
[LIMIT [offset,] row_count]
[channel_option]

channel_option:
FOR CHANNEL channel

在副本的中继日志中显示事件。如果未指定’log_name’，则显示第一个中继日志。该语句对源没有影响。 显示中继事件需要REPLICATION SLAVE特权。

LIMIT子句的语法与SELECT语句的语法相同。

发出没有LIMIT子句的显示中继事件可能会启动一个非常耗时和资源消耗的过程，因为服务器将中继日志的完整内容(包括所有修改副本已接收到的数据的语句)返回给 Client 端。

可选的FOR CHANNEL channel子句使您可以命名该语句应用于哪个复制通道。提供FOR CHANNEL channel子句可将该语句应用于特定的复制通道。如果没有命名通道并且不存在其他通道，则该语句将应用于默认通道。

使用多个复制通道时，如果显示中继事件语句没有使用FOR CHANNEL channel子句定义的通道，则会生成错误。

显示中继事件在中继日志中为每个事件显示以下字段：

Log_name
列出的文件的名称。

Pos
事件发生的位置。

Event_type
描述事件类型的标识符。

Server_id
发生事件的服务器的服务器 ID。

End_log_pos
源的二进制日志中此事件的End_log_pos值。

Info
有关事件类型的更多详细信息。此信息的格式取决于事件类型。

显示中继事件的输出中未包含与用户和系统变量的设置有关的某些事件。要完整了解中继日志中的事件，请使用mysqlbinlog。

https://www.docs4dev.com/docs/zh/mysql/5.7/reference/show-relaylog-events.html

5、分析从库执行速度慢的操作，例如，存在大量的delete_row()操作

这时我们根据主库对应的执行语句，可以适当在对应表建立主键或索引，优化对语句的数据处理，提升执行速度。

6、再次执行show slave status； 结果中Slave_SQL_Running_State字段： Slave has read all relay log; waiting for more updates Seconds_Behind_Master字段值为0 至此，数据库恢复正常。