目录python
1、MySQL的slow log中Query_time包含了lock_wait_time吗?mysql
首先给一个slow log的头部示例:sql
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
其中:
一、Query_time为SQL的消耗时间,包括了Lock_time
二、Lock_time为锁等待的时间,包括行锁、MDL锁等
三、是否记录slow log的断定条件为SQL的实际执行时间(Query_time - Lock_time)是否超过long_query_time,或者是否开启log_queries_not_using_indexes微信
2、为何MySQL的data目录下有不少innodb_status.xxx文件?网络
一、当MySQL启动时添加选项--innodb-status-file或my.cnf设置innodb_status_file = 1,会在data目录下生成innodb_status.xxx文件session
二、当打开选项innodb_status_output选项后,每隔约15秒即会刷新innodb status信息到文件中(手动show engine innodb status数据也会写入文件),并可能影响性能异步
三、当打开选项innodb_status_output选项后,innodb status信息及innodb row lock/deadlock信息(打开innodb_status_output_locks选项)也会以追加的方式写入到error log,可能致使error log文件过大,请务必注意这一点性能
四、innodb_status.xxx的xxx是当前mysqld的pid,即innodb_status.pid学习
五、正常关闭时MySQL会自动删除innodb_status.pid文件,当异常关闭mysqld时,会留下上次启动的innodb_status.pid文件,当屡次异常关闭后data目录下就会产生不少innodb_status.pid文件优化
3、MySQL参数eqrange index dive limit的做用以及如何理解index dive?
首先解释一下什么是index dive:
在MySQL里只要存在范围查找方法,就能够经过索引下潜来估计范围内的行数,方法是找出范围的开始和结束,并计算出他们之间的行数。这项技术更精确,因此也是制定良好执行计划的一个基础。
而参数eq_range_index_dive_limit限定了进行索引下潜的等值条件的最大值+1,
一、当等值条件个数大于或等于eq_range_index_dive_limit,那么优化器将直接使用统计信息
二、当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:
4、请用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]]
(一)第三方库numpy
a = [[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]]
5、你平时在作SQL优化的时候一般会用到哪些简单有效的手段呢?
(一)SELECT
掌握范式跟JOIN的关系 就能区分单表查询和JOIN的关系
一、单表SELECT
(1)查询列是否含有没有用的部分
(2)查看执行计划是否使用了索引
(3)含有ORDER BY LIMIT 能够考虑延迟JOIN
二、多表JOIN 查询
(1)肯定好驱动表
(2)被驱动表必须含有索引
(3)减小JOIN次数 ,尤为是含有GROUP BY的SQL中能够考虑先聚合后JOIN
(二)INSERT
一、跟磁盘IO关系很大
二、INSERT SELECT 结构 若是慢首先要查看SELECT
(三)UPDATE
一、不要进行大事物更新,适当分批进行
二、查看是否含有锁竞争
三、不要使用WHERE条件的子查询,改为JOIN
(四)DELETE
一、大量删除能够考虑,建立表结构以后的改名
二、不要进行大事物更新,适当分批进行
三、查看是否含有锁竞争
四、不要使用WHERE条件的子查询,改为JOIN
6、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 | +--------------------------------------------+----------+
一、Rplsemisyncmasterstatus表示主库是否启用半同步
二、Rplsemisyncslavestatus表示从库是否启用加强半同步
三、Rplsemisyncmastertxavgwaittime表示等待slave响应的事务平均等待时间,若是该值比较大的话能够检查一下网络状况了
四、Rplsemisyncmastertxwaits表示slave响应的事务数,该值若是增加较快的话也须要检查准备之间的网络状况
五、Rplsemisyncmasteryestx表示加强半同步复制下的事务数
六、Rplsemisyncmasternotx表示异步复制的事务数,该值若是变化了,那么也须要检查半同步复制是否已经退化为异步复制,在退化时从error log也能够看到
七、Rplsemisyncmasterstatus表示当前节点是不是半同步master
7、MySQL半同步退化成异步复制之后,网络恢复后还会自动切换为半同步复制吗?
首先公布答案:是
一、即使会自动恢复,可是仍然须要作好监控,避免因为异步复制下的主从切换而致使数据丢失
二、金融支付环境建议将rpl_semi_sync_master_timeout设置为较大值,避免退化为异步复制
对文章感兴趣的朋友们能够加我哦,这里有一个乐于交友的人鸭!
微信:lvqingshan_