ProxySQL中首次登录时DSN数据库选择异常问题分析

问题现象

在使用ProxySQL作为MySQL中间件时，发现一个关于数据库选择的有趣现象：当用户首次通过caching_sha2_password认证方式连接ProxySQL时，DSN中指定的目标数据库会被忽略，而实际连接的是mysql_users表中配置的default_schema或默认的information_schema数据库。只有在后续连接中，客户端指定的数据库才会被正确识别和使用。

技术背景

ProxySQL是一个高性能的MySQL协议代理，常用于数据库负载均衡和查询路由。caching_sha2_password是MySQL 8.0引入的默认认证插件，它采用两阶段认证机制：首次连接时进行完整认证，后续连接使用缓存快速认证。

问题复现步骤

1. 在MySQL服务器上创建使用caching_sha2_password认证的用户
2. 为用户授予两个不同数据库的访问权限（例如dbA和dbB）
3. 在ProxySQL中配置该用户，设置default_schema为dbA
4. 使用包含database=dbB参数的DSN首次连接ProxySQL
5. 执行SHOW TABLES命令，发现显示的是dbA的表而非dbB的表
6. 尝试查询dbB中的表会收到"表不存在"错误
7. 断开后重新连接，此时数据库选择行为恢复正常

问题分析

深入分析这个问题，我们可以发现几个关键点：

1. 认证流程影响：问题仅发生在首次完整认证阶段，快速认证阶段表现正常，说明问题与caching_sha2_password的认证流程有关。

2. 数据库上下文丢失：在完整认证过程中，ProxySQL似乎没有正确传递客户端请求的初始数据库上下文，而是回退到用户配置的默认值。

3. 设计意图：ProxySQL的这种行为可能是出于安全考虑，在完整认证阶段限制某些操作，但这种隐式的数据库切换会给用户带来困惑。

解决方案

ProxySQL开发团队已经确认这是一个需要修复的问题，并在3.0版本分支中提供了修复方案。对于当前受影响的用户，可以考虑以下临时解决方案：

1. 在应用层增加重试逻辑，处理首次连接时的数据库切换问题
2. 避免依赖首次连接时的数据库选择，在连接后显式执行USE语句
3. 考虑降级认证方式（虽然不推荐，但在某些场景下可能适用）

最佳实践建议

1. 对于关键业务系统，建议在ProxySQL用户配置中明确设置default_schema
2. 应用代码应具备处理数据库切换的容错能力
3. 监控ProxySQL版本更新，及时应用包含此修复的版本
4. 在测试环境中充分验证数据库选择行为，确保符合预期

这个问题提醒我们，在使用中间件时，需要充分理解其与底层数据库的交互细节，特别是在认证和安全相关的功能上。ProxySQL团队对此问题的快速响应也体现了开源社区对产品质量的重视。