mysqlreport是常用的MySQL状态分析工具，其中Com_分类记录了各类SQL命令的执行次数，change_db对应切换默认数据库的操作。如果该指标占用比例过高，说明实例存在大量无意义的数据库切换行为，会增加连接开销，拖慢整体响应速度。
change_db指标过高的常见原因
首先要明确change_db的触发场景：当客户端执行USE db_name语句，或者连接建立时指定了默认数据库之外的库，都会产生该操作。常见的高占比原因有以下几类：
- 应用连接池配置不当，每次获取连接后都主动执行USE语句切换数据库，即使后续操作都在同一个库内
- 应用代码中频繁切换不同数据库，没有合理规划数据访问逻辑，同一个连接反复切换默认库
- 多租户场景下，每个租户对应独立数据库，每次请求都根据租户ID切换数据库，没有做连接复用优化
- 部分框架或ORM工具的默认行为，在初始化连接时强制指定数据库，或者每次查询前都重置默认库
对应的解决方法
1. 优化连接池配置
检查连接池的初始化参数，确保连接建立时就指定好默认的数据库，避免后续重复切换。以Java的HikariCP连接池为例，正确配置方式如下：
// HikariCP配置示例，初始化时直接指定默认数据库
HikariConfig config = new HikariConfig();
// 直接把数据库名拼接到JDBC URL中，连接建立后默认使用该库
config.setJdbcUrl("jdbc:mysql://127.0.0.1:3306/business_db?useUnicode=true&characterEncoding=utf8");
config.setUsername("root");
config.setPassword("123456");
// 禁止连接后自动执行USE语句的配置，避免额外切换
config.addDataSourceProperty("useLocalSessionState", "true");
HikariDataSource dataSource = new HikariDataSource(config);
2. 调整应用代码逻辑
排查代码中是否存在不必要的USE语句调用，尽量保证同一个连接的生命周期内，只操作同一个数据库。如果确实需要跨库查询，优先使用库名.表名的方式指定表，而不是切换默认库。例如原本的代码：
-- 不推荐的写法，会触发change_db USE order_db; SELECT * FROM order_info WHERE user_id = 1; USE user_db; SELECT * FROM user_info WHERE id = 1;
可以修改为：
-- 推荐的跨库查询写法，不会触发change_db SELECT * FROM order_db.order_info WHERE user_id = 1; SELECT * FROM user_db.user_info WHERE id = 1;
3. 多租户场景的优化方案
如果是多租户架构下每个租户对应独立数据库的场景，可以采用连接池分组的方式，按照租户对应的数据库拆分连接池，每个连接池的连接都固定指向同一个数据库，请求到来时根据租户ID获取对应连接池的连接，避免同一个连接反复切换数据库。同时可以结合useLocalSessionState参数，让MySQL客户端直接使用本地缓存的数据库状态，减少和服务端的交互。
4. 调整框架或ORM的默认行为
部分ORM框架比如MyBatis、Hibernate可能会有默认的数据库切换逻辑，需要检查框架配置，关闭不必要的自动切换功能。例如在MyBatis的配置中，不要在每个SqlSession中都指定默认的catalog，而是直接在映射文件的表名中带上库名前缀。
验证优化效果
优化完成后，可以再次运行mysqlreport工具，查看Com_分类下的change_db占比是否下降。正常情况下，该指标的占比应该低于1%，如果仍然偏高，需要再次排查是否有遗漏的切换逻辑，或者是否存在短连接过多的问题，短连接频繁建立销毁也会带来额外的change_db开销，此时可以考虑增加连接保活配置，减少短连接的创建频率。
mysqlreportchange_dbMySQL性能优化Com_指标修改时间：2026-06-10 10:15:22