mysql复制是同步还是异步_MySQL主从复制结构下，如何判定是异步复制还是半同步复制？...

目录MySQL的slow log中Query_time包含了lock_wait_time吗？

MySQL参数eqrange index dive limit的作用以及如何理解index dive?

用python转换

你平时在做SQL优化的时候通常会用到哪些简单有效的手段呢？

MySQL主从复制结构下，如何判定是异步复制还是半同步复制？

MySQL半同步退化成异步复制以后，网络恢复后还会自动切换为半同步复制吗？

一、MySQL的slow log中Query_time包含了lock_wait_time吗？

首先给一个slow log的头部示例：

Time: 2019-10-08T08:46:34.635823Z

User@Host: root[root] @ localhost [] Id: 16

Query_time: 0.064742 Lock_time: 0.000460 Rows_sent: 1 Rows_examined: 9997

其中：

1、Query_time为SQL的消耗时间，包括了Lock_time

2、Lock_time为锁等待的时间，包括行锁、MDL锁等

3、是否记录slow log的判定条件为SQL的实际执行时间(Query_time - Lock_time)是否超过long_query_time，或者是否开启log_queries_not_using_indexes

二、为什么MySQL的data目录下有很多http://innodb_status.xxx文件？

1、当MySQL启动时添加选项--innodb-status-file或my.cnf设置innodb_status_file = 1，会在data目录下生成http://innodb_status.xxx文件

2、当打开选项innodb_status_output选项后，每隔约15秒即会刷新innodb status信息到文件中(手动show engine innodb status数据也会写入文件)，并可能影响性能

3、当打开选项innodb_status_output选项后，innodb status信息及innodb row lock/deadlock信息(打开innodb_status_output_locks选项)也会以追加的方式写入到error log，可能导致error log文件过大，请务必注意这一点

4、http://innodb_status.xxx的xxx是当前mysqld的pid，即innodb_status.pid

5、正常关闭时MySQL会自动删除innodb_status.pid文件，当异常关闭mysqld时，会留下上次启动的innodb_status.pid文件，当多次异常关闭后data目录下就会产生很多innodb_status.pid文件

三、MySQL参数eqrange index dive limit的作用以及如何理解index dive?

首先解释一下什么是index dive:

在MySQL里只要存在范围查找方法，就可以通过索引下潜来估计范围内的行数，方法是找出范围的开始和结束，并计算出他们之间的行数。这项技术更精确，所以也是制定良好执行计划的一个基础。

而参数eq_range_index_dive_limit限定了进行索引下潜的等值条件的最大值+1，

1、当等值条件个数大于或等于eq_range_index_dive_limit，那么优化器将直接使用统计信息

2、当eq_range_index_dive_limit设置为0时，优化器将始终进行索引下潜，而不用索引统计信息

例如有如下SQL:

select * from t where col_name IN(val1, ..., valN)，当eq_range_index_dive_limit为N+1，优化器就会使用index dive来计算执行计划costindex dive适用条件有以下形式

(1) col_name IN(val1, ..., valN)

(2) col_name = val1 OR ... OR col_name = valN

col_name为非唯一索引8.0以后优化器在满足以下条件可能会跳过index dive，而8.0以前无法避免index dive：查询时只访问一张表，而不是多表关联

force index(某个索引)

没有子查询

没有涉及全文索引

没有GROUP-BY or DISTINCT

没有ORDER-BY

四、请用python一条语句将:

a = [[1, 2, 3], [4, 5, 6], [7, 8, 9],[11,12,13]] 转换为

[[1, 4, 7, 11], [2, 5, 8, 12], [3, 6, 9, 13]]

(一)第三方库numpya = [[1, 2, 3], [4, 5, 6], [7, 8, 9]]import numpy as np

np.mat(a).T

matrix([[1, 4, 7],

[2, 5, 8],

[3, 6, 9]])

(二)列表推导式a = [[1, 2, 3], [4, 5, 6], [7, 8, 9]][[row[i] for row in a] for i in range(len(a[0]))]

[[1, 4, 7], [2, 5, 8], [3, 6, 9]]

五、你平时在做SQL优化的时候通常会用到哪些简单有效的手段呢？

(一)SELECT

掌握范式跟JOIN的关系 就能区分单表查询和JOIN的关系

1、单表SELECT

(1)查询列是否含有没有用的部分

(2)查看执行计划是否使用了索引

(3)含有ORDER BY LIMIT 可以考虑延迟JOIN

2、多表JOIN 查询

(1)确定好驱动表

(2)被驱动表必须含有索引

(3)减少JOIN次数 ,尤其是含有GROUP BY的SQL中可以考虑先聚合后JOIN

(二)INSERT

1、跟磁盘IO关系很大

2、INSERT SELECT 结构 如果慢首先要查看SELECT

(三)UPDATE

1、不要进行大事物更新，适当分批进行

2、查看是否含有锁竞争

3、不要使用WHERE条件的子查询，改成JOIN

(四)DELETE

1、大量删除可以考虑，创建表结构之后的更名

2、不要进行大事物更新，适当分批进行

3、查看是否含有锁竞争

4、不要使用WHERE条件的子查询，改成JOIN

六、MySQL主从复制结构下，如何判定是异步复制还是半同步复制？

对于半同步的监控可以采用如下方式：

mysql> show global status like '%Rpl_semi%';

+--------------------------------------------+----------+

| Variable_name | Value |

+--------------------------------------------+----------+

| Rpl_semi_sync_master_clients | 1 |

| Rpl_semi_sync_master_net_avg_wait_time | 0 |

| Rpl_semi_sync_master_net_wait_time | 0 |

| Rpl_semi_sync_master_net_waits | 2 |

| Rpl_semi_sync_master_no_times | 1 |

| Rpl_semi_sync_master_no_tx | 1 |

| Rpl_semi_sync_master_status | OFF |

| Rpl_semi_sync_master_timefunc_failures | 0 |

| Rpl_semi_sync_master_tx_avg_wait_time | 38391398 |

| Rpl_semi_sync_master_tx_wait_time | 76782796 |

| Rpl_semi_sync_master_tx_waits | 2 |

| Rpl_semi_sync_master_wait_pos_backtraverse | 0 |

| Rpl_semi_sync_master_wait_sessions | 0 |

| Rpl_semi_sync_master_yes_tx | 2 |

| Rpl_semi_sync_slave_status | OFF |

+--------------------------------------------+----------+

1、Rplsemisyncmasterstatus表示主库是否启用半同步

2、Rplsemisyncslavestatus表示从库是否启用增强半同步

3、Rplsemisyncmastertxavgwaittime表示等待slave响应的事务平均等待时间，如果该值比较大的话可以检查一下网络情况了

4、Rplsemisyncmastertxwaits表示slave响应的事务数，该值如果增长较快的话也需要检查准备之间的网络情况

5、Rplsemisyncmasteryestx表示增强半同步复制下的事务数

6、Rplsemisyncmasternotx表示异步复制的事务数，该值如果变化了，那么也需要检查半同步复制是否已经退化为异步复制，在退化时从error log也可以看到

7、Rplsemisyncmasterstatus表示当前节点是否是半同步master

七、MySQL半同步退化成异步复制以后，网络恢复后还会自动切换为半同步复制吗？

首先公布答案：是

1、即便会自动恢复，但是仍然需要做好监控，避免由于异步复制下的主从切换而导致数据丢失

2、金融支付环境建议将rpl_semi_sync_master_timeout设置为较大值，避免退化为异步复制

对文章感兴趣的朋友们可以加我哦，这里有一个乐于交友的人鸭！

微信：lvqingshan_