CHAR函数在不同数据库中行为差异显著：MySQL支持多参数且返回字符串，SQL Server仅接受单整数并转为空字符串而非NULL，PostgreSQL不支持CHAR()而需用chr()且范围限0–255；跨库使用易报错，应优先采用字符串字面量或应用层处理。
CHAR函数在不同数据库中的行为差异
SQL标准里没有统一的CHAR函数，它在MySQL、SQL Server、PostgreSQL中实现方式完全不同，直接套用会报错。MySQL用CHAR()，SQL Server也叫CHAR()但参数含义相反，PostgreSQL压根不认这个函数名——它用chr()。别看到“CHAR”就以为通用。
常见错误现象：CHAR(65)在MySQL返回'A'，在SQL Server也返回'A'，但在PostgreSQL执行会报错ERROR: function char(integer) does not exist。
- MySQL：支持多参数，
CHAR(65, 66, 67)→'ABC' - SQL Server：只接受单个整数，
CHAR(65)→'A'；注意它把0当作空字符串，不是NULL - PostgreSQL：必须用
chr(65)，且只支持0–255范围（单字节），超出会报错ERROR: chr() argument must be between 0 and 255
ASCII码转字符时的边界和编码陷阱
ASCII定义的是0–127，但CHAR()实际常接受0–255（尤其在MySQL/SQL Server中），这部分属于扩展ASCII或Latin-1。一旦传入128以上，在UTF-8环境里可能生成乱码或不可见控制字符。
比如CHAR(169)在MySQL里返回版权符号©（Latin-1编码），但若客户端连接字符集是utf8mb4，而服务端没正确声明，可能显示为。
- 确保连接层字符集一致：MySQL加
SET NAMES utf8mb4，SQL Server检查COLLATE是否匹配 - 避免使用128–255之间的值做业务逻辑，跨库迁移极易出问题
- 需要Unicode字符（如中文）？别用
CHAR()，改用CONVERT（SQL Server）、UNHEX()（MySQL）或chr()配合UTF-8字节序列（PostgreSQL）
替代方案：安全跨数据库的写法
如果SQL要跑在多个数据库上，硬写CHAR()或chr()必然失败。最稳妥的方式是用字符串字面量代替，或者封装成视图/函数隔离差异。
例如想表示换行符：不要依赖CHAR(10)，直接写'
'（MySQL/PostgreSQL支持），SQL Server则用CHAR(10)——但得用条件判断。
- MySQL：支持
UNHEX('0A')表示换行，UNHEX('E4B8AD')表示UTF-8编码的“中” - PostgreSQL：用
decode('0a', 'hex')或E'\x0a'字节串 - SQL Server：用
CONVERT(VARCHAR, 0x0A)，或CHAR(10)（仅限ASCII控制符）
真正麻烦的是带业务语义的字符拼接，比如生成分隔符+时间戳。这种场景建议把转换逻辑移到应用层，SQL只负责拼接已知字符串。
CHAR函数性能与执行计划影响
CHAR()本身开销极小，但容易被误用在WHERE或JOIN条件里，导致索引失效。比如写WHERE name = CHAR(65)，优化器可能无法识别这是常量'A'，尤其在复杂表达式中。
更隐蔽的问题是隐式类型转换：SQL Server里CHAR(65)返回char(1)，而字段是varchar(50)，比较时会触发类型转换，影响执行计划。
- 始终用显式字符串字面量代替
CHAR()用于等值判断，如WHERE status = 'A' - 若必须动态生成字符（比如批量构造测试数据），确保
CHAR()出现在SELECT列表或INSERT VALUES中，而非过滤条件 - 在MySQL中，
CHAR(N USING utf8mb4)语法可指定字符集，但仅限5.5+，旧版本不支持
真正难调试的是字符集隐式转换引发的排序异常，比如ORDER BY CHAR(225)在不同collation下结果不同——这比函数本身更值得花时间确认。
