POWER函数要求两参数均为数值类型，底数为负且指数非整数时会报错；SQRT仅支持非负数，负数输入需用CASE WHEN预处理。
POWER函数怎么用？参数顺序和类型容易错
SQL里的POWER函数不是“底数在前、指数在后”就万事大吉——很多新手传入字符串或NULL时没报错但结果为NULL，其实是隐式转换失败导致的静默失效。它要求两个参数都为数值类型（NUMERIC、FLOAT等），且第二个参数支持小数（比如POWER(2, 0.5)等价于√2）。
-
POWER(4, 2)→ 16，没问题；但POWER('4', 2)在PostgreSQL里直接报错，在SQL Server里可能转成0 - 负数底数+非整数指数会出错：例如
POWER(-2, 0.5)在多数数据库中抛出“无效的浮点运算”或返回NULL - MySQL中
POWER是POW的别名，两者完全等价；而Oracle只认POWER，不支持POW
SQRT函数的输入限制比想象中严格
SQRT只接受单个参数，且必须 ≥ 0。它不处理负数，也不做自动取绝对值——传SQRT(-9)在PostgreSQL里报cannot take square root of a negative number，SQL Server返回NULL，MySQL则返回NULL但不报错，容易掩盖逻辑缺陷。
- 如果字段可能为负，务必先过滤或用
CASE WHEN x >= 0 THEN SQRT(x) ELSE NULL END -
SQRT对0和1是安全的，但注意浮点精度：比如SQRT(0.0001)可能返回略大于0.01的值（取决于底层实现） - 某些旧版SQLite（SQRT，需用
POWER(x, 0.5)替代，但要注意前述负数问题
用POWER模拟SQRT时，指数写0.5还是1/2？
写POWER(x, 0.5)是通用做法；写POWER(x, 1/2)在多数SQL方言里会先算整数除法得0，最终变成POWER(x, 0)→恒为1（除非x=0且数据库特殊处理）。这是典型“看着对、跑出来错”的坑。
- MySQL/PostgreSQL/SQL Server中，
1/2是整数除法，结果为0；必须写1.0/2或0.5 - Oracle稍特殊：
1/2自动转为NUMBER类型，结果是0.5，但依赖上下文，不建议依赖 - 性能上，原生
SQRT通常比POWER(x, 0.5)快10%~20%，因有专门优化路径
跨数据库兼容写法怎么平衡？
没有一行代码通吃所有数据库，但可控制分支点数量。核心原则：优先用原生SQRT，仅当不可用时降级为POWER(x, 0.5)，并显式处理负数。
- 通用安全写法：
CASE WHEN x >= 0 THEN SQRT(x) ELSE NULL END（适用于支持SQRT的库） - 若需兼容无SQRT的SQLite，改用：
CASE WHEN x >= 0 THEN POWER(x, 0.5) ELSE NULL END - 避免在WHERE中直接用
SQRT(x) > 5——有些数据库无法下推索引，改用x > 25等价转换更高效
实际用的时候，最常被忽略的是负数输入的防御性检查，而不是函数本身怎么写。
