MySql 8不使用空间索引。
我有一个名为SHAPE的空间列，其中包含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 |
+----+-------------+--------------------+------------+------+---------------+------+---------+------+-------+----------+-------------+这清楚地表明，查询没有使用空间索引。
我在MySQL5.7中运行了相同的查询，它使用的是空间索引。
有人能帮我吗。我还需要注意其他的构形变化吗？
回答 2
Stack Overflow用户
发布于 2020-06-10 18:55:38
(这并不能回答问题，但可能会增加一些洞察力。)
8.0.4 Changelog说(我添加了粗体)：
不相容的变化：以前是，这些空间函数忽略了空间参考系统的几何参数和笛卡尔平面上的计算结果。它们现在支持几何参数的计算，这些参数指定地理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_Envelope 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_StartPoint()、ST_StartPoint()，ST_Y()。
在此之前，ST_GeoHash()空间函数接受带有任何SRID的点。ST_GeoHash()现在只接受SRID 0或4326的点。备注
如果空间数据包含的几何值现在由刚才列出的函数以不同的解释，那么使用这些函数的现有查询将返回与以前的MySQL版本不同的结果。
我的评论：什么是4269？也许只有4326被处理了？它能用4326跑得更快吗？
Stack Overflow用户
发布于 2020-10-03 21:27:21
我读了这篇文章后就解决了这个问题：https://dba.stackexchange.com/questions/260757/mysql-8-not-using-spatial-index
基本上，您需要在创建表(或使用ALTER)时为您的列定义一个默认的SRID。
在您的示例中，表geoid10中的列tl_2019_us_zcta510应该用SRID 4269定义，然后它应该正确地使用空间索引。对我起作用了。
这是dba.stackexchange.com网站Nikita引用的正确答案：
SRID属性使空间列SRID受到限制，这具有以下含义：
列只能包含具有给定SRID的值。尝试使用不同的SRID插入值会产生错误。
优化器可以在列上使用空间索引。见8.3.3节，“空间索引优化”。
没有SRID属性的空间列不受SRID限制，并接受任何SRID的值。但是，优化器在修改列定义以包含SRID属性之前不能对它们使用空间索引，这可能要求首先修改列内容，以便所有值都具有相同的SRID。
https://stackoverflow.com/questions/62297352
复制相似问题
腾讯云开发者
