ST_Within()需配合空间索引、合法WKT多边形及正确坐标顺序（经度在前）才能高效准确使用；否则易全表扫描或静默返回NULL。
ST_Within() 是电子围栏判定的核心函数，但直接用它可能查得慢甚至不准
MySQL 8.0+ 的 ST_Within() 确实能判断一个点是否在多边形内，语法也简单：ST_Within(POINT(long, lat), POLYGON((...)))
但它不是“开箱即用就快”的函数。真实场景中，如果你每次查询都临时构造 POLYGON 字符串、或对没索引的字段反复调用，性能会断崖式下跌。
常见错误现象：
- 查询耗时从几毫秒飙到数秒，尤其围栏数量 > 100 个时
-
EXPLAIN显示type: ALL（全表扫描） - 返回
NULL而不是0/1，实际是多边形 WKT 格式有非法坐标或首尾点未闭合
关键前提：
- 多边形数据必须存在表中，且字段类型为
POLYGON或GEOMETRY - 该字段必须建空间索引：
SPATIAL INDEX (geom_col)，普通 B-tree 索引无效 - 输入点要用
ST_Point(lng, lat)构造（注意：经度在前，纬度在后）
示例建表与索引：
CREATE TABLE fences ( id INT PRIMARY KEY, name VARCHAR(100), boundary POLYGON NOT NULL, SPATIAL INDEX(boundary) );
WKT 多边形必须合法，否则 ST_Within() 直接返回 NULL
MySQL 对 WKT 格式非常严格。哪怕只是少写一个括号、坐标顺序反了、或首尾点不重合，ST_Within() 就会静默返回 NULL——而不是报错，这极易被忽略。
容易踩的坑：
- 用百度/高德 API 获取的行政区划坐标，常以“纬度, 经度”顺序返回，但 MySQL
POLYGON要求 经度, 纬度 - 坐标数组末尾没闭合：WKT 要求第一个点和最后一个点完全相同，例如
((116.3 39.9, 116.4 39.9, 116.4 39.8, 116.3 39.9)) - 包含非法值：如
NaN、INF、空字符串，或超出经纬度范围（经度 > 180 或
验证方法：
- 先用
ST_IsValid(geom)检查多边形是否合法 - 再用
ST_AsText(geom)看原始 WKT 是否符合规范 - 插入前强制用
ST_GeomFromText()构造，并捕获警告：INSERT INTO fences VALUES (1, 'xxx', ST_GeomFromText('POLYGON((...))'));
大批量点实时判定时，别只靠 ST_Within() 单挑
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
单次查一个点 + 一个围栏，ST_Within() 没问题。但如果是“10 万个设备上报点，每秒批量判是否出围栏”，纯靠它会拖垮数据库。
更合理的做法是分层过滤：
- 第一层：用地理网格（如 Geohash 前缀或经纬度分桶）快速排除明显在外的围栏，减少
ST_Within()调用次数 - 第二层：对候选围栏集合，用
ST_Within()精确判定 - 可选第三层：若围栏极多（如城市级商圈 > 1w 个），把围栏按区域预分组，先查所属行政区域再查组内围栏
性能关键点：
-
ST_Within()在有空间索引时，复杂度接近 O(log n)，但 n 是“可能覆盖该点的围栏数”，不是总围栏数 - 避免在
WHERE子句里对点字段做函数计算，例如ST_Within(ST_Point(lng, lat), boundary)中的lng/lat必须是常量或来自关联表的已索引字段，不能是表达式结果
ST_Distance_Sphere() 适合圆形围栏，但别和 ST_Within() 混用
圆形电子围栏（比如“半径 500 米内”）其实更适合用 ST_Distance_Sphere()，它基于球面距离，精度高且可走空间索引：
ST_Distance_Sphere(POINT(lng, lat), center_point)
注意区别：
-
ST_Within()判定的是几何包含关系，适用于任意形状（多边形、矩形、不规则商圈） -
ST_Distance_Sphere()判定的是球面距离阈值，只适合圆形，但计算更稳定、边界无歧义
别犯的错：
- 把
ST_Distance_Sphere()和ST_Within()放在同一查询里做冗余判断 - 用
ST_Distance()（平面欧氏距离）代替ST_Distance_Sphere())，后者在跨纬度时误差可达公里级
真正难的不是函数怎么写，而是围栏数据怎么入库、怎么校验、怎么分层调度——这些环节出一点偏差，后面所有查询都会“看起来对，实际错”。
