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