Show proceslist时发现大量的sleep，有什么风险吗，该如何处理？

Show proceslist时发现大量的sleep，有什么风险吗，该如何处理？

MySQL如何对只对个别列授权？

如何正确监控MySQL主从复制延迟(请考虑5.6版本前后区别，即并行复制及GTID等因素)?

一、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反推找到相关应用负责人，协商优化方案。

二、MySQL如何对只对个别列授权？

答：其实挺简单的，用GRANT授权即可，例如：

GRANT SELECT (c1), INSERT (c1, c2) ON zhishutang.yewen TO 'yewen'@'zhishutang.com'

三、如何正确监控MySQL主从复制延迟(请考虑5.6版本前后区别，即并行复制及GTID等因素)?

答：基于Binlog和Postion复制

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工具。

查看当前连接

show processlist

在MYSQL的默认设置中，如果一个数据库连接超过8小时没有使用(闲置8小时)，服务器将断开这条连接，后续在该连接上进行的查询 *** 作都将失败。

解决办法：修改MYSQL服务器的配置参数

方法一：修改/etc/my.cnf

在这个文件中添加一行wait_timeout=你需要设置的超时时间（单位是秒）

方法二：通过mysql shell修改

查看：show global variables like 'wait_timeout'

修改：set global wait_timeout=3600

set global interactive_timeout=3600

1确切的说，是连接和线程关联，而不是账号。一般是一个客户端连接（可以是客户端工具的一个连接或应用程序创建的一个连接），服务端会启动一个线程给予服务，连接做完一些事情（比如查询或更新等 *** 作）后close连接，则线程会被设置为空闲（其销毁则由服务端来控制）。2服务端有线程池（连接池）的技术，可能你连接时正好使用的是一个已创建好的但空闲的连接线程，也可能是立即创建的新线程。3查看服务端线程相关设置：showvariableslike'thread%'thread_handling(这个就是处理连接的线程模式)默认是one-thread-per-connection,即一个连接一个线程；thread_concurrency(线程的并发数)thread_cache_size(线程缓存池的大小)，服务端如果性能好，可以设得较大点。

---