spatial索引不支持行级锁，所有dml操作均触发表锁，因其底层r-tree无全局线性序，无法定义“前/后值”，故不能实现间隙锁与临键锁，innodb退化为表级锁机制。
SPATIAL索引不支持行级锁，所有DML操作都会触发表锁
MySQL的SPATIAL索引底层用R-tree实现，而InnoDB的行级锁（记录锁、间隙锁、临键锁）完全依赖B+树的有序键结构。R-tree中几何对象的MBR（Minimum Bounding Rectangle）是多维边界，没有全局线性序，无法定义“前一个值”或“后一个值”，因此InnoDB根本无法在空间列上做精准行定位加锁。
这意味着：INSERT、UPDATE、DELETE哪怕只影响1行空间数据，也会持有X表锁；ALTER TABLE ... ADD SPATIAL INDEX等价于LOCK TABLES t WRITE，阻塞所有并发读写。
- InnoDB 5.7+虽支持
POINT等类型建SPATIAL索引，但锁行为与MyISAM一致——退化为表级锁 - MyISAM下更彻底：所有操作（包括
SELECT）都走表锁，MBRIntersects()会自动加READ锁 - 即使查询走了
SPATIAL索引，InnoDB也只能加意向排他锁（IX），实际执行常升级为全表扫描+表锁
为什么SPATIAL索引无法使用间隙锁和临键锁
间隙锁（GAP LOCK）和临键锁（Next-Key Lock）是InnoDB在REPEATABLE READ隔离级别下防止幻读的核心机制，但它们严格依赖B+树索引中键值的可比较性和区间可定义性。R-tree的MBR之间无法做“a ”这样的全局排序判断，MySQL自然无法构造出“(prev_mbr, next_mbr)”这样的间隙区间。
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
-
WHERE ST_Within(geom, ST_Polygon(...))这类条件不会产生任何间隙锁 - 事务中执行空间查询后，其他事务仍可插入新几何对象并提交，当前事务再次查询可能看到新行——即存在不可重复读
-
UNIQUE SPATIAL INDEX语法被禁止，因为R-tree无法保证唯一性校验所需的锁语义
对比B+树索引：锁粒度、并发表现与风险差异
B+树索引（如主键、普通INDEX）能精确到单行加锁，配合间隙锁可控制范围，而SPATIAL索引在锁机制上是“降级”的：它放弃精细控制，换来了查询逻辑的多维适配能力，代价是并发吞吐量和一致性保障双双下降。
- 高并发写入场景下，
SPATIAL索引极易成为瓶颈，哪怕只更新几条地理围栏数据，也会卡住整张表 - 空间查询看似走了索引，但因无法加行锁，优化器可能放弃索引选择全表扫描，尤其当匹配行数占比高时
- 若业务需强一致性（如订单地理围栏校验），不能依赖
SPATIAL索引本身的锁行为，得靠应用层加分布式锁或改用B+树模拟（如拆解经纬度为lat/lng字段建联合索引）
实际开发中容易忽略的关键点
很多人以为只要建了SPATIAL索引，空间查询就“自动高效且安全”，但真正上线后才发现锁冲突严重、事务隔离性弱于预期。最常被忽略的是：R-tree的锁退化不是Bug，而是设计使然——它本就不是为高并发事务场景设计的。
- 建表时声明
geom列必须NOT NULL，否则SPATIAL INDEX创建失败，但这个限制和锁无关，纯语法约束 -
ST_Distance()类函数无法走SPATIAL索引（无MBR覆盖关系），会强制全表计算，此时连表锁都避免不了 - 如果只是做静态地理围栏匹配（无高频更新），用MyISAM反而更轻量；若需事务支持，优先考虑用B+树+四叉树编码（如Geohash）替代原生
SPATIAL
