SIGN()函数返回1、-1、0或NULL：正数返1，负数返-1，零返0，NULL通常返NULL（MySQL/SQL Server一致，旧版SQLite可能转0）；需用CASE显式处理所有分支，避免WHERE中直接用SIGN()导致NULL行被意外过滤。
SQL中SIGN()函数返回值到底是哪些
SIGN()在主流数据库（MySQL、PostgreSQL、SQL Server、SQLite）中行为一致：输入正数返回1，负数返回-1，零或NULL返回0或NULL（注意：MySQL对NULL输入返回NULL，而SQL Server也返回NULL；但某些旧版SQLite可能将NULL转为0）。这不是“判断布尔真假”，而是明确的三态整数输出。
常见误用是直接写WHERE SIGN(amount) = 1却忽略amount为NULL时整个表达式结果为NULL，导致该行被WHERE过滤掉——这不是bug，是三值逻辑的正常表现。
用CASE WHEN配合SIGN()做安全分类标记
直接用SIGN()数值本身不够语义化，生产环境推荐包裹一层CASE，显式处理所有分支，尤其不能漏掉NULL和零值。
CASE WHEN amount IS NULL THEN 'unknown'WHEN SIGN(amount) = 1 THEN 'positive'WHEN SIGN(amount) = -1 THEN 'negative'ELSE 'zero' END AS sign_label
注意ELSE捕获SIGN()返回0的情况（即原始值为0），避免把零误标为NULL或漏标。不要写成WHEN SIGN(amount) = 0单独判断——冗余且易遗漏NULL前置检查。
不同数据库对SIGN()的兼容性细节
Oracle是个例外：它没有内置SIGN()函数，得用DECODE(SIGN(amount), 1, 'positive', -1, 'negative', 'zero')或改用CASE；而PostgreSQL支持SIGN()但要求参数为数值类型，传字符串会报错function sign(unknown) does not exist。
性能上无需担心：SIGN()是标量函数，无IO开销，但若字段未索引，配合WHERE SIGN(amount) = 1无法走索引——此时应改写为WHERE amount > 0才能利用索引。
当需要分组统计正/负/零数量时怎么写
别用子查询套SIGN()再GROUP BY，直接在SELECT里用条件聚合更高效：
SELECT COUNT(*) FILTER (WHERE amount > 0) AS positive_cnt, COUNT(*) FILTER (WHERE amount < 0) AS negative_cnt, COUNT(*) FILTER (WHERE amount = 0) AS zero_cnt, COUNT(*) FILTER (WHERE amount IS NULL) AS null_cnt FROM transactions;
这是PostgreSQL写法；MySQL需改用SUM(IF(amount > 0, 1, 0))；SQL Server用SUM(IIF(amount > 0, 1, 0))。核心原则：用原始比较条件替代SIGN()，既清晰又保索引友好性。
真正容易被忽略的是零值和空值在业务语义中的区别——比如“余额为0”和“余额未知”必须分开标记，不能只依赖SIGN()的0笼统覆盖。
