叶问20

《叶问》是知数堂新设计的互动栏目,不定期给大家提供技术知识小贴士,形式不限,或提问、或讨论均可,并在当天发布答案,让大家轻轻松松利用碎片时间就可以学到最实用的知识点。

2019年10月08日,周二

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

2019年10月10日,周四

MySQL的data目录下有很多innodb_status.xxx文件,咋回事?

1、当MySQL启动时添加选项--innodb-status-file或my.cnf设置innodb_status_file = 1,会在data目录下生成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、innodb_status.xxx的xxx是当前mysqld的pid,即innodb_status.pid

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

2019年10月17日,周四

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

PS:看到这条叶问的同学有福了,一般人我还不告诉他,好书推荐⎢《千金良方——MySQL性能优化金字塔法则》发布了,小编也入手了一本

2019年10月22日,周二

请用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]]

PS:为更好地给广大关注和支持《叶问》的同学提供服务,希望各位同学能够将自己平时遇到的问题或者困扰填写上来,我们会择优选择问题进行解答。

提交地址:https://www.wenjuan.com/s/MRvAVv/

2019年10月24日,周四

你平时在做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

详情:视频回放⎜《资深DBA带你学习SQL开发和优化》

2019年10月29日,周二

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

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

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

  2. +--------------------------------------------+----------+

  3. | Variable_name | Value |

  4. +--------------------------------------------+----------+

  5. | Rpl_semi_sync_master_clients | 1 |

  6. | Rpl_semi_sync_master_net_avg_wait_time | 0 |

  7. | Rpl_semi_sync_master_net_wait_time | 0 |

  8. | Rpl_semi_sync_master_net_waits | 2 |

  9. | Rpl_semi_sync_master_no_times | 1 |

  10. | Rpl_semi_sync_master_no_tx | 1 |

  11. | Rpl_semi_sync_master_status | OFF |

  12. | Rpl_semi_sync_master_timefunc_failures | 0 |

  13. | Rpl_semi_sync_master_tx_avg_wait_time | 38391398 |

  14. | Rpl_semi_sync_master_tx_wait_time | 76782796 |

  15. | Rpl_semi_sync_master_tx_waits | 2 |

  16. | Rpl_semi_sync_master_wait_pos_backtraverse | 0 |

  17. | Rpl_semi_sync_master_wait_sessions | 0 |

  18. | Rpl_semi_sync_master_yes_tx | 2 |

  19. | Rpl_semi_sync_slave_status | OFF |

  20. +--------------------------------------------+----------+

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

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

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

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

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

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

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

2019年10月31日,周五

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

首先公布答案:是

小编提醒:

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

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

猜你喜欢

转载自www.cnblogs.com/allenhu320/p/12188014.html