Druid SQL解析器对CREATE USER语句引号处理的缺陷分析

问题背景

在使用Druid 1.1.21版本处理MySQL用户创建语句时，发现当SQL语句中包含双引号时，解析器会错误地添加额外的引号。例如原始SQL语句：

create user "ptscr-2kaq"@"%" identified by "asdasdasdasd";

经过Druid解析后会变成：

CREATE USER 'ptscr-2kaq'@'"%"' IDENTIFIED BY '"asdasdasdasd"';

这种转换会导致创建的用户名、主机名和密码都不符合预期，特别是密码部分会被错误地包含在引号中。

技术分析

MySQL用户创建语法规范

在MySQL中，CREATE USER语句支持多种引号使用方式：

1. 使用单引号：'username'@'host'
2. 使用双引号："username"@"host"
3. 使用反引号：`username`@`host`

这三种方式在MySQL中都是合法的，且语义相同。Druid作为SQL解析器，应该保持这些引号使用的原始语义。

Druid解析器的问题

当前版本的Druid在处理这个问题时存在两个缺陷：

1. 引号类型强制转换：将所有标识符引号统一转换为单引号，破坏了原始SQL的语义
2. 引号嵌套问题：在转换过程中错误地保留了原始双引号，导致引号嵌套

这种处理方式特别在密码字段上会造成严重问题，因为密码中的引号会被当作密码的一部分存储。

影响范围

此问题主要影响以下场景：

1. 使用双引号创建MySQL用户的应用程序
2. 依赖Druid进行SQL重写或美化的工具
3. 需要精确保持SQL语句原貌的审计系统

解决方案

该问题已在Druid的后续版本(1.2.22)中得到修复。修复方案主要包括：

1. 保持原始SQL中的引号类型
2. 正确处理标识符和字符串字面量的引号嵌套
3. 确保密码字段的引号处理符合MySQL规范

最佳实践建议

对于需要使用Druid处理CREATE USER语句的开发人员，建议：

1. 升级到已修复该问题的Druid版本
2. 在应用程序中统一使用单引号格式，避免解析歧义
3. 对于密码等敏感字段，考虑使用参数化查询而非字符串拼接

总结

SQL解析器对引号的处理看似简单，但实际上关系到SQL语句的精确语义。Druid作为广泛使用的Java数据库连接池和SQL解析器，其解析准确性对应用程序至关重要。这次CREATE USER语句的引号处理问题提醒我们，在使用SQL解析工具时需要特别注意其与特定数据库语法的兼容性。