《叶问》第11期

关 于 叶 问

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

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的增长情况

 

扫码加入QQ技术交流群

MySQL 8.0|MGR研究院-ZST

（QQ群号：650149401）