PI() 是返回固定值3.141592653589793的常量函数，非动态计算；地理计算中角度转弧度必须除以180，正确写法为×PI()/180或RADIANS()，直接×PI()会导致错误。
PI() 在地理计算中不是“算π”，而是固定常量代入
SQL 中的 PI() 函数不参与任何实时数值推导，它只是返回硬编码的 3.141592653589793。你在地理场景里用它算圆周长、扇形面积或角度换算时，本质上是在拼接一个浮点常量——和直接写 3.141592653589793 完全等价。别指望它能“适应地球曲率”或“动态精度调整”，它就是个带括号的数字。
角度转弧度必须除以 180，漏掉就全错
GIS 场景下最常见错误：把经纬度角度值直接乘 PI() 当弧度用。比如想把 45° 转成弧度，写成 45 * PI() 是错的；正确写法是 45 * PI() / 180 或更清晰的 RADIANS(45)（如果数据库支持）。MySQL、PostgreSQL、SQL Server 都有原生 RADIANS()，优先用它，避免手算出错。
-
SELECT SIN(45 * PI() / 180)→ 正确，≈ 0.707 -
SELECT SIN(45 * PI())→ 错误，算的是 sin(141.37...) ≈ −0.92，毫无地理意义 - TDengine 的
PI()同样适用此规则，且明确要求配合SIN/COS时必须先完成单位转换
别在 WHERE 条件里对 PI() 做复杂表达式
像 WHERE ABS(2 * PI() * radius - circumference) 这类写法，既无法走索引，又掩盖了数据本源问题。真实地理数据中，圆周长本就不可能严格等于 <code>2 * PI() * r（地球非完美球体、测量误差、坐标系投影变形）。这类校验更适合放在应用层做容忍判断，而不是塞进 SQL 过滤条件。
- 批量计算圆形覆盖范围（如基站信号半径）时，用
ST_DistanceSphere()（MySQL）或ST_DWithin()（PostGIS）比手写PI()公式更可靠，它们内部使用优化过的球面模型，π 取值与PI()不同但更贴合地理实际 - 若必须手算（如兼容旧系统），确保所有涉及
PI()的列都定义为DOUBLE，避免DECIMAL截断导致精度丢失
高精度需求必须外部传入，SQL 层没法解决
MySQL 和 TDengine 的 PI() 最多提供 15–17 位有效数字，PostgreSQL 同样受限于 DOUBLE PRECISION。如果你在做高精度大地测量、卫星轨道模拟或科研级误差分析，数据库层的 PI() 就不够用了。
- Python 应用层可传入
decimal.Decimal('3.1415926535897932384626433832795')拼 SQL，或用math.pi计算后再入库 - 千万别试图用蒙特卡洛法（如
WITH RECURSIVE投点）在生产 SQL 里“重算 π”——性能极差、结果不稳定、还容易触发递归深度限制 - Oracle 用户注意：
PI()不可用，得用ACOS(-1)替代，但同样只是 double 精度，别误以为它更准
真正关键的不是 π 多精确，而是你用它的地方是否匹配业务语义：地理距离用球面函数，平面缓冲区用几何库，纯数学推导才轮到 PI() —— 它只是工具箱里一把固定尺寸的尺子，不是万能刻刀。
