调参优化jdbc初始连接时的性能消耗

背景

mysql-connector-java JDBC驱动是java开发数据库相关应用重要的组件，绝大多数场景下默认的设置即可以满足需求。但最近有个业务场景，导致了需要重新审视对jdbc的使用，这篇文章用以记录。

描述

同事反馈业务在集群扩容部分5.7从库之后碰到了一些问题，总会有大量show variables where的查询请求，导致5.7的节点响应变慢。而集群的特点是流量都很大。实际的SQL如下。

/* mysql-connector-java-5.1.20 ( Revision: [email protected] ) */SHOW VARIABLES WHERE 
Variable_name ='language' OR Variable_name = 'net_write_timeout' OR Variable_name = 'interactive_timeout' OR Variable_name = 'wait_timeout' OR Variable_name = 'character_set_client' OR Variable_name = 'character_set_connect
ion' OR Variable_name = 'character_set' OR Variable_name = 'character_set_server' OR Variable_name = 'tx_isolation' OR Variable_name = 'transaction_isolation' OR Variable_name = 'character_set_results' OR Variable_name = 't
imezone' OR Variable_name = 'time_zone' OR Variable_name = 'system_time_zone' OR Variable_name = 'lower_case_table_names' OR Variable_name = 'max_allowed_packet' OR Variable_name = 'net_buffer_length' OR Variable_name = 'sq
l_mode' OR Variable_name = 'query_cache_type' OR Variable_name = 'query_cache_size' OR Variable_name = 'init_connect'

实际执行的效果如下：

+------------------------+-----------------+
| Variable_name          | Value           |
+------------------------+-----------------+
| character_set_client   | utf8            |
| character_set_results  | utf8            |
| character_set_server   | latin1          |
| init_connect           |                 |
| interactive_timeout    | 28800           |
| lower_case_table_names | 0               |
| max_allowed_packet     | 4194304         |
| net_buffer_length      | 16384           |
| net_write_timeout      | 60              |
| query_cache_size       | 1048576         |
| query_cache_type       | OFF             |
| system_time_zone       | CST             |
| time_zone              | SYSTEM          |
| transaction_isolation  | REPEATABLE-READ |
| tx_isolation           | REPEATABLE-READ |
| wait_timeout           | 28800           |
+------------------------+-----------------+

解决

因为我们接入了数据库中间件，开始怀疑是类似SQL导致中间组件变慢。结合以前使用的中间组件，同事说MyCat等的处理方式是略过类似SQL做过滤。经过本地抓包和断点查看，在我们的中间件是直接透过到MySQL的。而且查找show variables where，可以看到这种是比较耗时的操作，因此，原因是大量show variables where导致MySQL自身变慢。

再回到开始，确认了这些SQL是通过mysql-connector-javajdbc驱动触发的，在查看源码后，锁定了具体的实现逻辑，具体在com.mysql.jdbc.ConnectionImpl#loadServerVariables (5.1.45版本)。在这里，发现可以通过设置参数，让jdbc驱动对show variables where请求添加缓存，可以减少对实际mysql的请求压力。具体参数是cacheServerConfiguration，实际配置可以如下:

jdbc:mysql://127.0.0.1:3306/biz?characterEncoding=UTF-8&autoReconnect=true&zeroDateTimeBehavior=convertToNull&useUnicode=true&useSSL=false

最开始想到的是要么在中间件层面直接过滤或者加缓存，这样其实是把压力放到了中间件这里。当然损耗按说不太大，如果jdbc驱动本身是支持了缓存，直接配置可用，当然是最方便的方式。经过验证包括业务反馈的版本mysql-connector-java 5.1.20 ，
测试了包括5.1.20,5.1.45,8.0.22，都支持该参数的设置。关于更多jdbc参数的说明，可以看后面的参考资料。

但这里要注意的是，这个配置是在连接层面控制的，并不是在全局，因此只有在连接做重连的时候生效，因此，可能的收益不是很大，但对于一些极端情况会有一定作用。

参考资料

1. MySQL jdbc 参数url