SIGN函数返回-1、0或1，分别表示负数、零、正数，不返回布尔值或字符串；对NULL输入返回NULL，不可直接用于布尔判断，需显式比对数值。
SIGN 函数直接返回 -1、0 或 1，不是布尔值，别用它做条件表达式里的真假判断
SQL 中 SIGN 的返回值含义必须记牢
SIGN 不是判断“是否为正”，而是严格按数学定义返回符号值：负数 → -1，零 → 0，正数 → 1。它不返回 TRUE/FALSE，也不返回字符串。很多初学者误以为 SIGN(x) = 1 是“最简正数判断”，其实这反而多了一次比较运算，且掩盖了零值的存在。
-
SIGN(-5)→-1 -
SIGN(0)→0 -
SIGN(3.14)→1
用 SIGN 实现分组或分类时的常见错误
想把数据按正/负/零三类打标签？别直接写 CASE WHEN SIGN(x) THEN 'positive'...——因为 SIGN(x) 在 WHEN 子句里会被当作布尔上下文处理（某些数据库如 PostgreSQL 会报错，MySQL 则把非零当真，导致 0 和负数都被归进 ELSE）。正确写法是显式比对返回值：
CASE SIGN(amount) WHEN -1 THEN 'negative' WHEN 0 THEN 'zero' WHEN 1 THEN 'positive' END
注意：SIGN 对 NULL 输入返回 NULL，所以如果字段可能为空，得额外加 WHEN NULL 或用 COALESCE(SIGN(x), 0) 处理（但这样会把 NULL 和 0 混淆）。
SIGN 在计算列和索引中的实际限制
有些用户想用 SIGN(price - cost) 快速标记盈亏方向，再在该列上建索引加速查询。但要注意：SIGN 是标量函数，多数数据库（如 MySQL 8.0 前、SQL Server）不支持直接对函数结果建普通 B-tree 索引；即使支持（如 PostgreSQL 的函数索引），SIGN 输出只有三个离散值，选择性极差，索引几乎无效。真要优化这类查询，不如在业务层预计算并存为 profit_flag TINYINT 字段，再对该字段建索引。
- MySQL 5.7 不支持函数索引，
INDEX(SIGN(x))语法错误 - PostgreSQL 支持
CREATE INDEX ON t ((SIGN(x)))，但扫描效率≈全表扫 -
SIGN不改变数值精度，但对浮点数慎用——SIGN(0.0000001)是1，而SIGN(-1e-20)是-1，边界情况需结合业务容忍度看
真正容易被忽略的是：不同数据库对 SIGN 处理 NaN 或溢出值的行为不一致，比如 SIGN(1/0) 在 PostgreSQL 报错，在 SQLite 返回 NULL，生产环境若涉及异常数值流，必须显式 IS NOT NULL 过滤后再用 SIGN。
