我的空间列名为 形状 与SRID 4269和空间索引。当我进行查询时
select geoid10 as zipcode from tl_2019_us_zcta510
where st_intersects(ST_GeomFromText('POINT(30.330280 -82.759009)',4269),SHAPE);
它需要2分钟的时间来运行。该表包含33k条记录。
我检查了查询是否使用索引
explain select geoid10 as zipcode from tl_2019_us_zcta510
where st_intersects(ST_GeomFromText('POINT(30.330280 -82.759009)',4269),SHAPE);
而我得到的结果是
+----+-------------+--------------------+------------+------+---------------+------+---------+------+-------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+--------------------+------------+------+---------------+------+---------+------+-------+----------+-------------+
| 1 | SIMPLE | tl_2019_us_zcta510 | NULL | ALL | NULL | NULL | NULL | NULL | 28206 | 100.00 | Using where |
+----+-------------+--------------------+------------+------+---------------+------+---------+------+-------+----------+-------------+
这清楚地表明,该查询没有使用空间索引。
我在Mysql 5.7中运行同样的查询,它使用空间索引。
有谁能帮我解决这个问题.是否有任何其他配置上的变化,我应该注意。
(这并不能回答问题,但可能会增加一些见解。)
该 8.0.4 变更日志说(我加了粗)。
不兼容的变化。以前,这些空间函数 漠视 的空间参考系(SRS),并在笛卡尔平面上计算结果。它们现在支持对指定地理 SRS 的几何参数的计算:ST_Distance_Sphere()、ST_IsSimple()、ST_IsValid()、ST_Length()。
以前,这些空间函数忽略了任何几何参数的 SRS,并在笛卡尔平面上计算结果。现在,当调用这些函数时,如果使用指定地理SRS的几何参数,它们会产生错误:ST_Area()、ST_Buffer()、ST_Centroid()、ST_ConvexHull()、ST_Difference()、ST_Envelope()。ST_Intersection()ST_IsClosed(), ST_MakeEnvelope(), ST_Simplify(), ST_SymDifference(), ST_Union(), ST_Validate()。
以前,这些空间函数允许使用未定义的 SRS 的几何参数。现在,当调用具有未定义 SRS 的几何参数时,它们会产生一个错误。ST_Dimension()、ST_Distance_Sphere()、ST_EndPoint()、ST_ExteriorRing()、ST_GeometryN()、ST_GeometryType()、ST_InteriorRingN()、ST_IsEmpty()、ST_IsSimple()。ST_IsValid()、ST_Length()、ST_NumGeometries()、ST_NumInteriorRing()、ST_NumInteriorRings()、ST_NumPoints()、ST_PointN()、ST_StartPoint()、ST_SwapXY()、ST_X()、ST_Y()。
以前,ST_GeoHash()空间函数接受任何SRID的点。现在ST_GeoHash()只接受SRID为0或4326的点。
如果空间数据包含的几何值现在是 众说纷纭 由刚才列出的函数,现有的查询使用这些函数将返回不同的结果,与以前的MySQL版本相比。
我的评论 4269是什么?也许只处理4326?用4326会不会跑得更快?