sign()返回1、-1、0或null：正数→1，负数→-1，零→0，null→null；需显式处理null，跨库使用时注意类型转换差异。
SQL中SIGN()函数的返回值规则是什么？
SIGN()对数值输入返回整数：正数返回1，负数返回-1，零返回0。它不处理NULL——直接返回NULL，这点容易被忽略。
- 输入
5.0→1 - 输入
-3.7→-1 - 输入
0→0 - 输入
NULL→NULL（不是0） - 输入字符串如
'12'在某些数据库（如MySQL）会隐式转换，但PostgreSQL会报错invalid input syntax for type numeric
用SIGN()做条件分类时怎么避免NULL干扰？
直接用SIGN(col) = 1筛选正数，会漏掉col为NULL的行，但更危险的是——如果col本身可能为NULL，SIGN(col)也是NULL，导致整个表达式判断失效。
- 写
WHERE SIGN(amount) = 1只能捕获非空正数 - 要包含“明确为正”+“排除NULL”，得加
AND amount IS NOT NULL - 更稳妥写法：
WHERE amount > 0语义更直白，且索引友好；SIGN()更适合嵌入表达式场景，比如生成分类标签
在CASE表达式里组合SIGN()要注意什么？
SIGN()常和CASE配合生成状态标签，但分支必须覆盖NULL情况，否则结果列会出现意外NULL。
CASE SIGN(balance) WHEN 1 THEN 'positive' WHEN -1 THEN 'negative' WHEN 0 THEN 'zero' ELSE 'unknown' -- 必须加这一行，否则balance为NULL时整个结果为NULL END
-
ELSE不能省；不写就等价于ELSE NULL - 如果业务上
NULL代表“未结算”，那ELSE 'pending'比'unknown'更准确 - PostgreSQL和SQL Server支持此写法；SQLite也支持；但老版本MySQL（SIGN(NULL)行为不稳定，建议升级或改用
IF(ISNULL(...), ...)
SIGN()在不同数据库里的兼容性差异
函数名统一叫SIGN()，但参数类型和NULL处理有细微差别：
- MySQL：接受任意数字类型，
SIGN('abc')返回0（静默转0），不推荐依赖 - PostgreSQL：严格类型检查，
SIGN(TEXT)报错，必须显式::NUMERIC - SQL Server：支持
FLOAT、INT等，但SIGN(0.0)和SIGN(-0.0)都返回0（IEEE浮点规则） - SQLite：只支持数值，
SIGN(NULL)返回NULL，行为最干净
实际写跨库SQL时，别假设SIGN()能自动兜底类型转换，尤其当字段来自JOIN或CAST结果时，先COALESCE(col, 0)或CAST(col AS NUMERIC)再套SIGN()更稳。
真正麻烦的不是函数本身，而是你没意识到它对NULL和隐式类型转换的沉默态度。
