Kysely项目中MSSQL连接池的性能优化问题分析

背景介绍

Kysely是一个类型安全的SQL查询构建器，最近在使用过程中发现其MSSQL方言实现存在一个潜在的性能问题。当执行用户定义的查询时，实际上会向数据库服务器发送3次查询请求，而不是预期的1次，这显著增加了应用程序的延迟。

问题现象

通过OpenTelemetry跟踪分析，可以观察到以下查询模式：

1. 从连接池获取连接时，会执行一个验证查询
2. 执行用户实际定义的查询
3. 释放连接回池时，会执行一个重置查询

这种三连查询模式导致了额外的两次数据库往返，增加了整体查询延迟。

技术分析

深入分析发现，这个问题源于两个层面的实现：

1. 连接池验证机制：当使用tarn连接池获取连接时，默认会调用验证方法执行一个测试查询，以确保连接的有效性。

2. 连接释放处理：当连接被释放回池时，会调用tedious驱动程序的reset方法，该方法内部会执行特定的重置查询。

行业对比

对比其他主流数据库驱动实现：

• PostgreSQL的pg驱动提供了可选的连接验证功能，但不强制使用
• MySQL的mysql2驱动既不验证也不重置连接
• 更高层次的mssql库(基于tedious)虽然提供了验证功能，但不会在释放时重置连接

这表明Kysely当前实现中的双重检查可能是不必要的严格。

解决方案

经过讨论，决定分阶段实施改进：

1. 第一阶段：添加配置选项

   • 引入validateConnections选项控制是否执行验证查询
   • 添加resetConnectionOnRelease选项控制是否在释放时重置连接
   • 保持默认行为不变以确保向后兼容

2. 第二阶段：调整默认行为

   • 将resetConnectionOnRelease默认值改为false
   • 与mssql库的行为保持一致
   • 这将是破坏性变更，需要谨慎处理

实现意义

这些改进将：

• 显著减少不必要的数据库往返
• 提高查询响应速度
• 提供更灵活的连接池配置选项
• 与其他数据库驱动实现保持一致

最佳实践建议

对于性能敏感的应用：

1. 评估连接验证的必要性
2. 考虑禁用连接重置功能
3. 监控连接健康状态作为替代方案
4. 在测试环境中验证配置变更的影响

这种优化特别适合高并发、低延迟要求的应用场景，可以有效减少数据库负载和查询延迟。