Azure App Insights中诡异SELECT ?查询的排查求助

可能的来源方向 #

• JDBC驱动预测试逻辑：MySQL JDBC驱动（如mysql-connector-java）在启用PreparedStatement相关配置时，可能发送参数占位符预测试语句，用于验证参数绑定机制，这类语句常表现为SELECT ?。
• Azure网络中间层：Azure云端应用连接本地MySQL时，流量可能经过Azure出站代理、VNet网关等网络组件，部分组件可能插入测试性查询。
• 连接池额外校验逻辑：除了validationQuery，HikariCP、Tomcat JDBC等连接池的高级配置（如连接预热、额外校验）可能触发此类语句。
• 监控组件注入：Azure App Insights的JDBC监控模块，可能在采集数据时插入测试语句以验证监控链路。

具体排查步骤 #

• 抓包验证流量真实性：在本地MySQL服务器使用tcpdump或Wireshark抓包，对比Azure App Insights日志中的SELECT ?与实际收到的SQL语句，确认该语句是应用侧发送还是中间层插入。
• 排查JDBC驱动配置：检查应用的JDBC URL参数，重点关注useServerPrepStmts、cachePrepStmts、prepStmtCacheSize等与PreparedStatement相关的配置；同时核对驱动版本，不同版本的MySQL驱动行为存在差异。
• 检查连接池详细配置：除validationQuery外，查看连接池的connectionTestQuery、testOnBorrow、testWhileIdle等参数，确认是否存在额外的连接校验或初始化逻辑；部分连接池在创建连接时会执行预热语句。
• 临时禁用App Insights数据库监控：关闭App Insights对JDBC的采集（如移除spring-boot-starter-azure-insights相关配置、禁用JDBC监控开关），观察SELECT ?是否仍出现，以此确认是否为监控组件注入。
• 调试追踪调用栈：本地启动应用并开启Debug模式，在com.mysql.cj.jdbc.ClientPreparedStatement的executeQuery方法处断点，追踪SELECT ?语句的触发方，查看完整调用栈定位来源。
• 检查自定义数据库组件：排查应用中的自定义JDBC拦截器、AOP切面、数据库相关自定义逻辑，确认是否存在主动发送测试语句的代码。

耗时优化补充 #

由于是Azure到本地的跨网络连接，SELECT ?的高耗时大概率来自网络往返开销。若确认该语句为驱动或连接池的默认逻辑，可通过调整JDBC或连接池配置关闭不必要的预测试/校验逻辑；若为中间层注入，需优化Azure网络链路（如使用VNet peering建立私有连接）降低延迟。

内容的提问来源于stack exchange，提问作者Yaroslav Miloslavsky