sqrt函数要求参数必须为非负数，因实数范围内负数无平方根，mysql/postgresql返回null，sql server/oracle报错；安全用法需配合case、abs或nullif处理边界，并注意类型精度与性能优化。
SQRT 函数只接受非负数，传入负数会返回 NULL 或报错，不是所有数据库都允许跳过校验。
SQL中SQRT(number) 为什么必须是非负数
数学上实数范围内负数没有平方根，SQL标准和主流数据库（MySQL、PostgreSQL、SQL Server、Oracle）都严格遵循这点。传入负数时行为略有差异：
- MySQL 和 PostgreSQL 返回
NULL - SQL Server 报错：
Msg 3623, Level 16, State 1: A domain error occurred. - Oracle 直接抛出异常：
ORA-01428: argument 'x' is out of range
所以不能依赖“自动忽略”，必须显式处理边界情况。
如何安全使用 SQRT 处理可能为负或 NULL 的字段
直接写 SQRT(price) 在 price 为负或 NULL 时不可靠。常见做法是结合 CASE 或 ABS()，但要注意语义是否合理：
- 用
CASE WHEN price >= 0 THEN SQRT(price) ELSE NULL END—— 保留业务含义：负价格无意义，不参与计算 - 用
SQRT(ABS(price))—— 仅在你明确需要“绝对值的平方根”时才用，比如做数值归一化，但会扭曲原始语义 - 用
COALESCE(SQRT(NULLIF(price, -1)), 0)—— 适合 price=-1 表示“未知”的场景，先转成 NULL 再 fallback 到 0
别漏掉 WHERE price IS NOT NULL，因为 SQRT(NULL) 恒为 NULL，但后续聚合（如 AVG(SQRT(price))）会把 NULL 当作缺失值跳过，容易造成统计偏差。
不同数据库对 SQRT 返回值类型的处理差异
虽然都返回浮点结果，但精度和类型名不一致，影响后续 cast 或比较：
- MySQL 返回
DOUBLE，SQRT(25)是5.0（注意尾部 .0） - PostgreSQL 返回
double precision，可直接参与::numeric转换 - SQL Server 返回
FLOAT，但SQRT(4)结果是2.0，和整型比较时需注意隐式转换 - Oracle 返回
NUMBER，精度由输入决定，SQRT(100)得10（无小数点），但SQRT(2)是高精度小数
跨库迁移或对接 BI 工具时，如果下游要求固定小数位，建议显式加 ROUND(SQRT(x), 4)，别依赖数据库默认格式。
真正容易被忽略的是：SQRT 不是标量函数的“万能解”，它不加速、不索引友好，大量行调用时性能开销明显；如果只是做范围过滤（比如“价格平方根 > 5”），不如改写成 price > 25——让优化器走索引。
