>我有一个名为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 |
+----+-------------+--------------------+------------+------+---------------+------+---------+------+-------+----------+-------------+
这清楚地表明查询未使用空间索引。
我在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 会跑得更快吗？
我读完这个后解决了： https://dba.stackexchange.com/questions/260757/mysql-8-not-using-spatial-index
基本上，您需要在创建表时(或使用 ALTER(为列定义默认 SRID。
在您的情况下，表tl_2019_us_zcta510中的geoid10列应使用 SRID 4269 定义，然后它应正确使用空间索引。 它对我有用。
这是尼基塔在 dba.stackexchange.com 引用的正确答案：
SRID 属性使空间列受 SRID 限制，该列具有 这些含义：
该列只能包含具有给定 SRID 的值。尝试 插入具有不同 SRID 的值会产生错误。
优化程序可以在列上使用空间索引。请参阅部分 8.3.3， "空间索引优化"。
没有 SRID 属性的空间列不受 SRID 限制，并且 接受具有任何 SRID 的值。但是，优化器不能使用空间 对它们进行索引，直到修改列定义以包含 SRID 属性，可能要求列内容首先 修改后，所有值具有相同的 SRID。