2018年11月6日，周二
Show proceslist时发现大量的sleep，有什么风险吗，该如何处理？
答：（一）可能的风险有：
1、大量sleep线程会占用连接数，当超过max_connections后，新连接无法再建立，业务不可用；
2、这些sleep线程中，有些可能有未提交事务，可能还伴随着行锁未释放，有可能会造成严重锁等待；
3、这些sleep线程中，可能仍有一些内存未释放，数量太多的话，是会消耗大量无谓的内存的，影响性能。
（二）建议应对措施：
1、升级到5.7及以上版本，连接性能有所提升；
2、采用MariaDB/Percona版本，根据情况决定是否启用thread pool功能；
3、适当调低wait_timeout/interactive_timeout值，例如只比java连接池的timeout时间略高些即可；
4、利用pt-kill或辅助脚本/工具巡查并杀掉无用sleep进程；
5、利用5.7的新特性，适当设置max_execution_time阈值，消除长时间执行的SQL；
6、定期检查show processlist的结果，找到长时间sleep的线程，根据host&port反推找到相关应用负责人，协商优化
2018年11月16日，周五
MySQL如何对只对个别列授权？
答：其实挺简单的，用GRANT授权即可，例如：
GRANT SELECT (c1), INSERT (c1, c2) ON zhishutang.yewen TO 'yewen'@'zhishutang.com';2018年11月20日，周二
如何正确监控MySQL主从复制延迟(请考虑5.6版本前后区别，即并行复制及GTID等因素)?
1、通过观察io线程减去sql线程对比的方式对比： Master_Log_File == Relay_Master_Log_File && Read_Master_Log_Pos == Exec_Master_Log_Pos。
基于GTID复制
2、通过接受事务数减去已经执行事务数对比：Retrieved_Gtid_Set == Executed_Gtid_Set。
基于并行复制
3、先通过P_S库replication_applier_status_by_coordinator和replication_applier_status_by_worker表来观察每个复制线程的状态，后配合postion复制或GTID复制方法来监控复制延迟。
4、可以采用pt-heartbeat工具。
大家不要再相信Seconds_Behind_Master。至于为什么，先卖个关子，关注下期叶问哦。
