工作中遇到的mysql小优化

事情是这样的：发现mongodb中由定时任务完成的数据采集数据断了，查看脚本日志，发现mysql报了2006的错误。以前也发现过这样的错误，但是一致没有找到好的方法结局，一致认为是python多线程连接数据库的方式需要优化。直至今日，使用了以下几条命令定位并解决了问题。

SHOW VARIABLES LIKE '%error'; 
"log_error"=>"/kknd/var/log/mysql/mysqld.log"
#mysql错误日志文件位置

SHOW VARIABLES LIKE 'log_warnings'; 
"log_warnings"=>"1"
#log_warnings=0,表示不记录告警信息；
#log_warnings=1,表示告警信息一并记录到错误日志中；
#log_warnigns>1,表示“失败的连接”的信息和创建新连接时“拒绝访问”类的错误信息也会被记录到错误日志中

于是，通过上面的命令我们就可以去日志里看看，问题刚发生的时候，mysql是什么状态的。

 于是，我们来看看mysql的这两个参数是不是1024和431，果然

现在，我们可以修改这两个参数了！

SHOW GLOBAL VARIABLES LIKE '%open_%';
"open_files_limit"=>"65535"


#1)10 + max_connections + (table_open_cache * 2)
#2)max_connections * 5
#3)open_files_limit value specified at startup, 5000 if none
#mysqld在启动的时候，根据上述三种算法对该变量进行调整，并取三种算法中的最大值。也就是说最终确定的open_files_limit 可能比你设定的大，也可能小。
（https://blog.csdn.net/weixin_36209030/article/details/113299337）

show variables like '%table_open_cache%';
"table_open_cache"=>"4096"


SHOW GLOBAL STATUS LIKE 'open%tables';
"Open_tables"=>"446"
"Opened_tables"=>"453"

table_open_cache指定表高速缓存的大小。每当MySQL访问一个表时，如果在表缓冲区中还有空间，该表就被打开并放入其中，这样可以更快地访问表内容。
通过检查峰值时间的状态值Open_tables和Opened_tables，可以决定是否需要增加table_open_cache的值。
如果你发现open_tables等于table_open_cache，并且opened_tables在不断增长，那么你就需要增加table_open_cache的值了(上述状态值可通过SHOW GLOBAL STATUS LIKE ‘Open%tables’获得)。
注意，不能盲目地把table_open_cache设置成很大的值，设置太大超过了shell的文件描述符(通过ulimit -n查看)，造成文件描述符不足，从而造成性能不稳定或者连接失败。 

比较适合的值：
Open_tables / Opened_tables >= 0.85
Open_tables / table_open_cache <= 0.95
如果对此参数的把握不是很准，有个很保守的设置建议：把MySQL数据库放在生产环境中试运行一段时间，然后把参数的值调整得比Opened_tables的数值大一些，并且保证在比较高负载的极端条件下依然比Opened_tables略大。