POWER函数参数顺序固定为POWER(base, exponent)，颠倒会导致计算错误；负底数需整数指数，否则报错；SQRT仅支持非负数且比POWER(x,0.5)更高效稳定。
POWER 函数的底数和指数参数顺序不能颠倒
POWER 是标准 SQL 数值函数，接受两个参数：base 和 exponent，顺序固定为 POWER(base, exponent)。常见错误是把指数写在前面，比如误写成 POWER(2, 3) 想算 3² —— 实际结果是 2³ = 8，不是 9。
实际使用中要注意：
- 底数为负数时，指数必须是整数（否则多数数据库报错或返回
NULL），例如POWER(-4, 2)可行，但POWER(-4, 0.5)在 PostgreSQL/SQL Server 中直接报错 - Oracle 对负底数 + 非整数指数会返回
ORA-01428: argument 'x' is out of range - 浮点精度问题：
POWER(10, 0.5)理论上等于 √10 ≈ 3.16227766，但不同数据库返回位数可能不同（如 SQLite 默认 12 位，MySQL 依赖double实现）
SQRT 函数只支持非负输入，且不等价于 POWER(x, 0.5)
SQRT 要求参数 ≥ 0，传入负数会直接报错：SQRT(-1) 在 MySQL 报 Invalid argument for SQRT()，PostgreSQL 返回 NaN 或报错（取决于 sqrt() 的实现模式）。
虽然数学上 SQRT(x) == POWER(x, 0.5)，但二者行为并不完全一致：
-
SQRT通常更快、更稳定，专为开方优化；POWER(x, 0.5)是通用幂运算，内部可能调用对数+指数，精度略低 - 某些数据库（如 older SQLite）不支持
SQRT，只能用POWER(x, 0.5)替代，但需先加CASE WHEN x 防错 - 当 x 接近 0（如 1e-300），
SQRT更可靠；而POWER(x, 0.5)在极端小值下可能下溢为 0
用 POWER 和 SQRT 做几何距离计算要小心 NULL 和单位一致性
计算二维点 (x₁,y₁) 到 (x₂,y₂) 的欧氏距离，公式是 SQRT(POWER(x2-x1, 2) + POWER(y2-y1, 2))。看似简单，但实战里容易漏掉这些细节：
- 任一坐标为
NULL，整个表达式结果为NULL（SQL 三值逻辑），需提前用COALESCE或CASE处理，比如COALESCE(x1, 0) - 如果坐标来自不同单位（如经纬度用度，但想算千米距离），不能直接套用欧氏公式 —— 地球曲率会让结果偏差极大；此时应换用
ST_Distance（PostGIS）或 Haversine 公式 - 在 WHERE 条件中用该表达式过滤（如 “距离小于 5km”），会导致全表扫描；建议预计算并建索引，或改用空间索引 +
ST_DWithin
复合科学计算中优先拆解中间变量，避免嵌套过深
比如计算圆锥体积 V = (1/3) × π × r² × h，写成单行：(1.0/3) * PI() * POWER(r, 2) * h 看似简洁，但调试困难、难以复用、且部分数据库（如 SQL Server）中 PI() 不是标准函数（需用 ACOS(-1.0) 替代）。
更稳妥的做法是分步声明或 CTE：
SELECT
(1.0/3) * pi_val * r_sq * h AS volume
FROM (
SELECT
ACOS(-1.0) AS pi_val,
POWER(r, 2) AS r_sq,
h
FROM measurements
) t;这样做有三个实际好处：
- 每一步可单独验证（比如检查
r_sq是否为负、是否溢出） - 便于替换常量（如用更高精度 π 近似值）
- 避免某些数据库对嵌套函数深度的限制（如旧版 SQLite 限制 10 层嵌套）
真正麻烦的从来不是函数本身，而是数据质量、边界值和跨库兼容性 —— 写完记得在目标数据库里跑一遍 POWER(-1, 1/3.0)，看看它到底认不认立方根。
