欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  IT编程

《叶问》第11期

程序员文章站 2022-11-20 22:27:46
关 于 叶 问《叶问》是知数堂新设计的互动栏目,不定期给大家提供技术知识小贴士,形式不限,或提问、或讨论均可,并在当天发布答案,让大家轻轻松松利用碎片时间就可以学到最实用......


关 于 叶 问


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


2018年12月04日,周二


大表,某列无索引,先需要查询该列,删除符合条件的记录,大约占40%数据量,请问有何更好的方案吗?

一、存在其他索引(主键、唯一索引、普通索引)的情况

1、可利用现有索引分段扫描全表,例如每次只读取1000条记录,然后再根据条件进行判断并删除数据(最好是进行归档,而不是真正删除)。

2、由于要删除掉的数据量比较大,会造成InnoDB表较多碎片,可以考虑用反向操作,也就是创建新表,把要保留的数据复制过去,最后再将两个表对调。

3、利用 pt-archiver 工具进行归档。


二、无任何索引的情况

1、真发生这种情况的话,负责的DBA或者相关同学麻烦引咎辞职吧。这句话是开玩笑的,嘿,不过说真的也太挫了。

2、观察条件列,如果区分度较高(不同值较多),就创建一个新索引,再根据索引删除数据。

3、对该表创建一个自增主键列,然后参考上述方案,根据主键索引分段扫描、判断、删除(归档)。


2018年12月11日,周二

MySQL所有的压力都在一个CPU核心上,为什么会产生这种现象,改如何解决?

一、为什么会产生这种现象?

事实上,并不是所有压力都在一个逻辑CPU上,其实是因为MySQL还不支持并行计算,因此一个会话中的SQL只会被分配到一个逻辑CPU上。

之所以出现这种现象,大概率是因为下面几种情况:

1、某个会话中正在执行慢SQL,尚未结束;

2、某个会话中的SQL开启了大事务,并且持有很多行锁或等待很多行锁,该事务尚未结束


二、如何解决?

1、检查是否有慢SQL,并进行优化

2、尽量不使用大事务,拆分成小事务

3、记住老司机的名言,当mysqld进程消耗CPU很高时,极大概率是有些SQL没索引导致

4、也可以尝试用perf top工具来排查具体什么原因导致


2018年12月18日,周二


监控MySQL的性能,应该主要观察那几个监控项?

一、liunx操作系统层面

1、整体cpu负载的%user最好不长期超过20%(若%user太高,有极大可能性是索引使用不当)

2、整体cpu负载的%iowat最好不长期超过10%(确认I/O子系统是否有明显瓶颈)

3、整体cpu负载的%idle最好保持在70%以上(让CPU保持低负载)

4、关注各个逻辑CPU之间的负载是否均衡(可能是中断不均衡导致性能问题)

5、关注是否有swap产生(注意关闭NUMA),可使用命令或工具:vmstat、sar、dstat等


二、MySQL状态层面

1、主要关注tps、qps、并发连接数(Threads_connected)、并发活跃线程数(Threads_running)、临时表(*tmp_disk_tables*)、锁(*locks_waited*, Innodb_row_lock*)等指标

2、关注当前是否有不良线程状态,例如:copy*to*tmp table、Creating sort index、Sorting result、Creating tmp table、长时间的Sending data等

3、关注InnoDB buffer pool page的使用情况,主要是Innodb*pages_free、Innodb*wait_free两个

4、关注InnoDB的redo log刷新延迟,尤其是checkpoint延迟情况,并关注unpurge list大小

5、关注innodb status中是否有long semaphore wait的情况出现

6、关注slow query sql的增长情况


 《叶问》第11期

《叶问》第11期扫码加入QQ技术交流群

MySQL 8.0|MGR研究院-ZST

(QQ群号:650149401)    

《叶问》第11期

本文地址:https://blog.csdn.net/n88Lpo/article/details/86110439