ASCII函数返回字符串最左侧字符的ASCII码整数值，仅处理首字符；返回类型为NUMBER（Oracle）或int（SQL Server、MySQL），NULL输入返回NULL，空字符串在MySQL中返回0，多字节字符仅取首字节值。
ASCII函数的基本用法和返回值类型
ASCII 函数在 SQL 中用于返回字符串第一个字符的 ASCII 编码值（整数），不是整个字符串。它只看第一个字符，其余忽略。不同数据库对空字符串、NULL 和多字节字符的处理差异很大，这点必须提前确认。
- PostgreSQL 和 SQL Server：输入
''（空字符串）会报错或返回 0，具体取决于版本；输入NULL返回NULL - MySQL：
ASCII('')返回 0；ASCII(NULL)返回NULL - Oracle：不支持
ASCII()，要用ASCII('A')（注意它其实是标准函数，但 Oracle 要求单字符输入，否则截取首字符） - 示例：
SELECT ASCII('A');→ 返回65；SELECT ASCII('abc');→ 也返回65，不是 65+98+99
常见错误：把ASCII当字符转义工具或批量处理函数
很多人误以为 ASCII 可以“转换整列字符串”，结果发现只取了首字符，或者遇到中文直接返回乱码/报错。根本原因在于：ASCII 编码只覆盖 0–127，超出范围（如汉字、emoji）在多数数据库里会返回 0、报错或不可预测值。
- MySQL 8.0+ 对非 ASCII 字符（如
'你好'）调用ASCII()返回0，不是 UTF-8 码点 - SQL Server 的
ASCII()作用于varchar类型，若字段是nvarchar（Unicode），会先隐式转为varchar再取首字节 —— 中文常变成?或 63 - 真正需要 Unicode 码点？用
UNICODE()（SQL Server）、ORD()（PostgreSQL）、ASCII(SUBSTR(...,1,1))配合字符集转换（MySQL）——但都不是标准ASCII()
替代方案：什么时候该换函数而不是硬扛ASCII
如果你实际想做的是“查某个字符是否是数字/字母/控制符”，或“按字节序排序”，ASCII() 可能不是最优解。尤其涉及国际化文本时，依赖它容易埋坑。
- 判断是否为数字字符：用
col REGEXP '^[0-9]$'（MySQL）或col ~ '^[0-9]$'（PostgreSQL），比ASCII(col) BETWEEN 48 AND 57更直观且安全 - 提取所有字符的编码？SQL 不适合循环，应考虑应用层处理；真要在数据库做，PostgreSQL 可用
string_to_array()+unnest()+ascii()组合 - 排序需求：直接
ORDER BY col通常比ORDER BY ASCII(col)更符合语义，后者只按首字符排序，且对大小写敏感逻辑混乱
跨数据库兼容性陷阱
写可移植 SQL 时，ASCII() 表面一致，实则行为割裂。比如同样执行 SELECT ASCII('€');：
- MySQL（utf8mb4）：返回
0（因 € 是 3 字节 UTF-8，ASCII()只读第一个字节 0xE2 → 超出 0–127） - PostgreSQL：返回
226（即 0xE2），但它不是 Unicode 码点，只是 UTF-8 编码的第一个字节值 - SQL Server（Latin1_General_CI_AS）：可能报错或返回
63（问号替换后的 ASCII） - 结论：只要数据含非 ASCII 字符，就别指望
ASCII()返回有意义的值；需要 Unicode 处理，优先查目标数据库的UNICODE/UTF8_BYTES/encode()等专用函数
SELECT ASCII('X') 测下当前库的行为，再决定要不要绕开它。字符编码这事，表面简单，底下全是方言。 
