MySql8 没有使用空间索引
MySql 8 is not using spatial index
我有一个名为 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 分钟。 table 包含 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 的点。
注意
如果空间数据包含的几何值现在被刚刚列出的函数 以不同方式解释,则使用这些函数的现有查询将 return 与以前的 MySQL 个版本。
我的评论:什么是4269?也许只处理了 4326?使用 4326 会 运行 更快吗?
看完这个我解决了:
https://dba.stackexchange.com/questions/260757/mysql-8-not-using-spatial-index
基本上,您需要在 table 创建(或使用 ALTER)时为您的列定义默认 SRID。
在您的情况下,table tl_2019_us_zcta510 中的 geoid10 列应使用 SRID 4269 定义,那么它应该正确使用空间索引。
它对我有用。
这是 Nikita 在 dba.stackexchange.com 引用的正确答案:
The SRID attribute makes a spatial column SRID-restricted, which has
these implications:
The column can contain only values with the given SRID. Attempts to
insert values with a different SRID produce an error.
The optimizer can use SPATIAL indexes on the column. See Section
8.3.3, “SPATIAL Index Optimization”.
Spatial columns with no SRID attribute are not SRID-restricted and
accept values with any SRID. However, the optimizer cannot use SPATIAL
indexes on them until the column definition is modified to include an
SRID attribute, which may require that the column contents first be
modified so that all values have the same SRID.
我有一个名为 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 分钟。 table 包含 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 的点。 注意
如果空间数据包含的几何值现在被刚刚列出的函数 以不同方式解释,则使用这些函数的现有查询将 return 与以前的 MySQL 个版本。
我的评论:什么是4269?也许只处理了 4326?使用 4326 会 运行 更快吗?
看完这个我解决了: https://dba.stackexchange.com/questions/260757/mysql-8-not-using-spatial-index
基本上,您需要在 table 创建(或使用 ALTER)时为您的列定义默认 SRID。
在您的情况下,table tl_2019_us_zcta510 中的 geoid10 列应使用 SRID 4269 定义,那么它应该正确使用空间索引。 它对我有用。
这是 Nikita 在 dba.stackexchange.com 引用的正确答案:
The SRID attribute makes a spatial column SRID-restricted, which has these implications:
The column can contain only values with the given SRID. Attempts to insert values with a different SRID produce an error.
The optimizer can use SPATIAL indexes on the column. See Section 8.3.3, “SPATIAL Index Optimization”.
Spatial columns with no SRID attribute are not SRID-restricted and accept values with any SRID. However, the optimizer cannot use SPATIAL indexes on them until the column definition is modified to include an SRID attribute, which may require that the column contents first be modified so that all values have the same SRID.