MySQL 5.7 中 GEOMETRY 类型 SPATIAL INDEX 中的慢速 ST_CONTAINS 查询答案

【问题标题】：Slow ST_CONTAINS query in GEOMETRY type SPATIAL INDEX in MySQL 5.7MySQL 5.7 中 GEOMETRY 类型 SPATIAL INDEX 中的慢速 ST_CONTAINS 查询
【发布时间】：2017-06-06 04:57:24
【问题描述】：

我有一个带有空间索引的表。当我运行这个查询时，返回结果需要 0.7 以上。有没有办法让这个查询更快？（AWS RDS、InnoDB 上的 MySQL 5.7.17）

创建表

CREATE TABLE `geofences` (
    `id` INT(11) UNSIGNED NOT NULL AUTO_INCREMENT,
    `sticker_key` VARCHAR(50) NOT NULL COLLATE 'utf8mb4_bin',
    `geofence` GEOMETRY NOT NULL,
    `location` VARCHAR(50) NULL DEFAULT NULL COLLATE 'utf8mb4_bin',
    `expires` VARCHAR(50) NULL DEFAULT NULL COLLATE 'utf8mb4_bin',
    PRIMARY KEY (`id`),
    SPATIAL INDEX `geofence` (`geofence`)
)COLLATE='utf8mb4_bin'
ENGINE=InnoDB;

查询

SELECT geofences.sticker_key FROM geofences WHERE ST_CONTAINS(geofences.geofence, POINT(126.924394,37.552754)) GROUP BY sticker_key;

解释

示例数据

这是我的地理围栏表中最小的一行。

MULTIPOLYGON(((126.982169151306 37.5796080752196,126.984980106354 37.5792084484235,126.985055208206 37.5801097313528,126.985623836517 37.5800672182523,126.985656023026 37.5802542757132,126.986804008484 37.5801947574811,126.9868683815 37.5831110948965,126.986482143402 37.5831961175971,126.986385583878 37.5830685835098,126.986138820648 37.5828475239075,126.98569893837 37.582711486903,126.985720396042 37.5819207668924,126.985355615616 37.5817762257676,126.984947919846 37.5817677233397,126.984915733337 37.5814616352904,126.9846367836 37.5814616352904,126.984508037567 37.5817082063176,126.984218358994 37.581878254826,126.983692646027 37.5820398005493,126.98362827301 37.5822608625499,126.983746290207 37.5823373838587,126.983370780945 37.5834086739237,126.983295679092 37.5834766918201,126.983370780945 37.5843269102809,126.983531713486 37.5843609188173,126.983789205551 37.5849730698168,126.982952356338 37.5850580903908,126.982877254486 37.5845139570391,126.982491016388 37.5845479654901,126.982126235962 37.5845564676004,126.982115507126 37.5846329865497,126.981954574585 37.5846329865497,126.981739997864 37.5837147539679,126.981611251831 37.5823118767645,126.981300115585 37.5819972885508,126.980999708176 37.5815041475947,126.98145031929 37.5812235659375,126.981514692307 37.581036510912,126.982115507126 37.5800162024996,126.982308626175 37.5799226735289,126.982169151306 37.5796080752196)))

有些更大（比如整个国家等等）

【问题讨论】：

在这种情况下，可能是 group by 需要很长时间。您是否尝试过不同的 group by？
@Shadow 是的，我使用了 DISTINCT 但没有区别
表中有多少行，它们包含哪些几何图形？
@duskwuff 11 行，都是多面体
每个几何图形有多少个多边形，有多少个点？这些是简单的还是复杂的形状？

标签： mysql sql gis

【解决方案1】：

简化您的几何形状！

形状越复杂，MySQL 判断它是否包含点所需的时间就越长——而且有些国家确实有非常复杂的形状。例如，印度尼西亚的边界（您在评论中提到）包含超过 18,000 个点，其中大部分定义了砂拉越和加里曼丹之间的复杂边界。

除非您的应用程序特别需要准确知道用户在该边界方面所处的位置，否则使用更简单的版本可能会更好。有许多工具可用于此目的；一种流行的是mapshaper。

【讨论】：

谢谢@duskwuff！我使用了您推荐的工具，它显着减少了点数（我可以通过查看文件大小看到这一点。从 13MB 到 500kb）。我已经可以看到显着的改进。我的下一个计划是使用带有 postgis 扩展的 postgresql。即使在 aws rds 上的 t2.micro 上，它在原始 geojson 上的表现也非常好。干杯！