MySQL ST_IsSimple 怎样判断 LineString 是否自相交

在空间数据导入后，最容易混淆的是“这段 WKT 能不能解析”“这个几何是否有效”和“这条 LineString 是否简单”其实是三件事。ST_IsSimple() 负责第三个问题：按空间标准判断几何是否满足简单性规则。对 LineString 来说，最常见的排查场景就是线段在中途穿过自己，查询结果通常会从 1 变成 0。

官方文档地址：https://dev.mysql.com/doc/refman/8.0/en/gis-general-property-functions.html

从一次导入排查开始：不要先把所有异常都叫“无效”

我在整理路线类数据时，通常先把异常拆成三层：第一层是数据能否被 MySQL 当成几何值读取，第二层是几何是否符合有效性要求，第三层才是某类几何是否满足简单性规则。这样做的好处是，导入失败、类型混用和线路自相交不会被同一个布尔字段掩盖。

例如，一条 LineString 能够被构造出来，并不意味着它一定是简单的；同样，ST_IsSimple() 返回 0，也不等于已经给出了修复方案。它更像是一个明确的筛选信号：告诉你要把这条数据送到复核或后续处理分支。

本文的示例都用 WKT 构造临时几何，目的是把判定边界讲清楚。真正接入表字段时，可以把示例中的变量替换成空间列。

ST_IsSimple 先看什么：LineString 的三个典型形状

先把三类形状放在一起看，最容易理解返回值：

下面的 SQL 只做最小对照。每个几何都先用 ST_GeomFromText 构造，再交给 ST_IsSimple。注意 SQL 注释说明的是示例目的，不是让注释代替查询结果：

-- 用三种 LineString 对照 ST_IsSimple 的返回值。
SET @plain_line = ST_GeomFromText('LINESTRING(0 0, 2 1, 4 0)');
SET @cross_line = ST_GeomFromText('LINESTRING(0 0, 4 4, 0 4, 4 0)');
SET @closed_line = ST_GeomFromText('LINESTRING(0 0, 4 0, 4 4, 0 0)');

SELECT
    ST_IsSimple(@plain_line) AS plain_is_simple,
    ST_IsSimple(@cross_line) AS cross_is_simple,
    ST_IsSimple(@closed_line) AS closed_is_simple;

这个对照的重点不是背下某个输出表，而是建立“形状—判定”的对应关系：普通折线作为基线，中段自相交作为异常样本，闭合端点作为需要单独解释的边界。不同空间参考系和几何类型要以当前 MySQL 版本的官方规则为准。

为什么中段自相交通常是 0：简单性看的是拓扑关系

LineString 的坐标序列只是输入表达，ST_IsSimple 关注的是这些线段连接后是否重复经过不该重复经过的内部位置。比如上面的 @cross_line 从左下走到右上，再折到左上，最后回到右下，中间两段穿过了已经走过的内部区域，这就不再是简单的线。

这里容易出现一个误区：不要把“坐标列表里没有重复字符串”当成“几何没有自相交”。两段线可能使用完全不同的端点坐标，却在中间相交。因此排查时要让 MySQL 按几何关系判断，而不是只用字符串搜索坐标。

另一个误区是，把首尾相同的闭合 LineString 一律视为错误。闭合形状本身可能是业务允许的环线表达；是否允许、是否需要 Polygon、是否要进入面数据流程，要由数据模型决定。ST_IsSimple 只负责给出简单性结果，不负责替业务决定几何类型。

重复节点、自相交和几何无效不是同一个字段

工程上更稳妥的做法，是把几何类型、简单性和有效性并列记录。重复相邻节点可能是采集设备的采样噪声；中段自相交可能是路线回穿；语法可解析但拓扑不符合要求又是另一层问题。它们的修复策略并不相同。

ST_IsValid() 也不能被简单理解成 ST_IsSimple() 的别名。前者用于判断几何是否满足有效性约束，后者回答是否满足简单性规则。对于需要做质量报表的表，可以先把几个信号一次性查出来：

-- 同时保留类型、简单性和有效性，避免只保存一个模糊状态。
SELECT
    id,
    ST_GeometryType(route_geom) AS geometry_type,
    ST_IsSimple(route_geom) AS is_simple,
    ST_IsValid(route_geom) AS is_valid,
    ST_AsText(route_geom) AS wkt_preview
FROM delivery_route
WHERE route_geom IS NOT NULL;

示例中的 wkt_preview 只用于人工复核和问题定位；生产表不应把完整 WKT 无限制地写入日志。对外输出时也可以只返回主键、类型、两个判定值和一个截断后的摘要。

把判断接进数据排查流程：先分流，再决定修复

如果只在导入脚本里执行一次 ST_IsSimple，很容易把结果变成“通过/失败”两个桶。我更推荐把它接到一个可追踪的分流流程中：先确认输入不是 NULL，再确认类型符合预期，然后分别计算简单性和有效性，最后按照业务策略进入接收、人工复核或后续几何处理。

-- 将判定结果变成可追踪的分流标签，实际规则按业务调整。
SELECT
    id,
    CASE
        WHEN route_geom IS NULL THEN 'missing'
        WHEN ST_IsValid(route_geom) = 0 THEN 'invalid-review'
        WHEN ST_IsSimple(route_geom) = 0 THEN 'self-intersection-review'
        ELSE 'accepted'
    END AS geometry_status
FROM delivery_route;

这个顺序是有意安排的：NULL 没有几何可判；有效性明显不满足时先进入无效复核；有效但不简单时，继续保留自相交这一更具体的业务信号。对于允许重复回路的路线数据，最终规则可以把 self-intersection-review 改成“允许但需要标记”，但不应静默丢掉原始判定。

上线前的四个边界：版本、类型、坐标系和修复责任

• 版本边界：空间函数的支持范围和错误行为要以部署版本的官方手册为准，不要把其他 GIS 引擎的规则直接套到 MySQL。
• 类型边界：本文聚焦 LineString。Polygon、MultiLineString 和 GeometryCollection 的简单性语义不同，不能只换一个函数名就当成同一问题。
• 坐标系边界：几何关系判断和经纬度范围错误是不同层次；输入带地理 SRS 时，还要关注坐标范围和 SRID。
• 责任边界：ST_IsSimple 只提供判断，不替你删除点、切分线或改写业务路线。修复动作必须保留原始数据、规则版本和人工决策记录。

如果文章读者只需要记住一条实践建议，就是不要用一个名为 is_valid 的布尔列承载所有空间质量判断。至少把 is_simple 和 is_valid 分开，后续才知道到底是线穿越自己，还是几何本身不满足有效性约束。

常见问题

ST_IsSimple 返回 0 就一定是坐标重复吗？

不一定。中段线段相交时可能没有重复坐标字符串；应按几何关系定位，不要只用文本去重。

闭合 LineString 一定不简单吗？

不能这样一概而论。首尾闭合是几何形状的一种表达，是否符合业务模型需要结合类型和标准判断。

ST_IsSimple 能替代 ST_IsValid 吗？

不能。两者回答不同问题，建议并列计算并分别进入质量报表。

发现自相交后能直接调用 ST_Validate 修复吗？

不要把检测函数当成通用修复器。先确认业务允许的修复策略，再保留原始几何、修复前后结果和处理原因。