MySQL中应优先使用CAST()或CONVERT()显式转换，避免隐式转换导致NULL或截断；CAST符合SQL标准、跨库兼容性好，CONVERT在MySQL中支持额外编码格式；PostgreSQL强制显式转换，常用::text；SQL Server推荐CONVERT()或FORMAT()；Oracle依赖TO_CHAR()精准控制格式。
MySQL里用CONVERT()和CAST()最稳，别依赖隐式转换
MySQL在SELECT或WHERE中把数字直接拼进字符串（比如CONCAT('id:', id)）会自动转，但这是靠隐式转换——一旦字段为NULL或值超范围，结果可能意外为NULL或截断。显式用CAST(id AS CHAR)或CONVERT(id, CHAR)更可控，且支持指定长度：CAST(id AS CHAR(10))。
-
CAST()是SQL标准，跨库迁移时兼容性更好 -
CONVERT()在MySQL里支持额外格式（如CONVERT(id USING utf8mb4)），但非必需场景不建议混用 - 隐式转换在
ORDER BY里尤其危险：写ORDER BY '1', '2', '10'会按字符串排序，结果是'1', '10', '2'，不是数值顺序
PostgreSQL必须显式转换，::text语法最常用
PostgreSQL几乎不搞隐式数字→字符串转换。写'id:' || 123会报错：ERROR: operator does not exist: text || integer。必须加类型转换：
- 用
::text后缀最简洁：'id:' || 123::text - 等价写法
CAST(123 AS TEXT)或TO_CHAR(123, '999999')（后者适合带格式，如补零、千分位） -
TO_CHAR()对NULL返回空字符串，而::text返回NULL，这点影响COALESCE逻辑
SQL Server的STR()有坑，优先用CONVERT()或FORMAT()
STR(num, len, decimal)看着方便，但默认右对齐、补空格，且len小于实际位数时返回**（比如STR(12345, 3) → '**'）。生产环境基本不用它：
- 用
CONVERT(VARCHAR(20), num)更直白，不截断也不补空格 - SQL Server 2012+ 推荐
FORMAT(num, 'N0')（带千分位）或FORMAT(num, 'D')（整数格式），但性能略低，高并发场景慎用 - 隐式转换只在极少数上下文发生（如赋值给
VARCHAR变量），绝不该依赖它做字符串拼接
Oracle的TO_CHAR()是唯一靠谱选择，||操作符会强制调用它
Oracle允许'id:' || 123，但这只是语法糖——底层自动调用TO_CHAR(123)，用的是数据库默认数字格式（可能丢失小数位或科学计数法）。真要控制输出，必须显式写：
-
TO_CHAR(123)→'123'（默认格式） -
TO_CHAR(123.456, 'FM999.00')→'123.46'（FM去前导空格，00强制两位小数） -
TO_CHAR(NULL)返回NULL，不是空字符串；需NVL(TO_CHAR(num), '')兜底
跨库写SQL时，最容易被忽略的是NULL值转换行为——MySQL/PostgreSQL/SQL Server转NULL得NULL，Oracle也一样，但拼接后整体是否为NULL，取决于各库对||或CONCAT()的空值处理策略。
