【译】MySQL服务博客 - InnoDB中的空间数据索引

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
RDS MySQL Serverless 高可用系列,价值2615元额度,1个月
云数据库 RDS PostgreSQL,高可用系列 2核4GB
简介: MySQL 8.0的一个重要特性是对地理业务的支持。MySQL现在已拥有一类功能称之为空间参考系统(SRS),其中近500个是地理区域相关的。大多数函数还支持地理计算。

MySQL 8.0的一个重要特性是对地理业务的支持。MySQL现在已拥有一类功能称之为空间参考系统(SRS),其中近500个是地理区域相关的。大多数函数还支持地理计算。大家可能会关心索引的功能的增强。

MySQL 8.0附带了用于地理数据的InnoDB空间索引。由于笛卡尔和地理数据的计算方式不同,因此不能在同一个索引中混合使用。实际上,在同一索引中的多个SRS中索引数据是没有意义的。因此,MySQL加强了几何列定义中的SRID限制。

SRID限制

在5.7及更早版本中,对于加索引的几何列的唯一要求是该类型应该是几何类型,并且该列不为空。不幸的是,我们允许将不同SRID中的几何数据插入到同一个索引中。这种做法毫无意义,尤其当某些几何体位于地理SRS中时,情况会变得更糟。

因此,MySQL 8.0增加了限制,几何列只有一个SRID:

mysql>  CREATE TABLE places  (
->  pk INT  PRIMARY KEY,
->  position POINT NOT  NULL  SRID  4326,
->  name VARCHAR(200)
->  );

Query OK,  0  rows affected  (0,00  sec)

如果我们试图在不同的SRID中插入一个几何体,会得到一个错误:

mysql>  INSERT INTO places VALUES  (1,  ST_GeomFromText('POINT(63.4269 10.3958)', 
 0),  'Nidaros Cathedral');

ERROR  3643  (HY000):  The SRID of the geometry does not  match the SRID of the column  'position'.  
The SRID of the geometry is  0,  but the SRID of the column is  4326.  Consider changing the SRID 
of the geometry or  the SRID property  of the column.

如果我们遵守SRID限制,则该点则可以插入:

mysql>  INSERT INTO places VALUES  (1,  ST_GeomFromText('POINT(63.4269 10.3958)', 
 4326),  'Nidaros Cathedral');

Query OK,  1  row affected  (0,00  sec)

有了这个限制,MySQL确保我们不会将同一列中不同SRID中的数据混合在一起,从而使列可以索引。

另一件事是锁定SRID。在SRID限制中它被使用,服务器不允许我们drop掉SRS:

mysql>  DROP SPATIAL REFERENCE SYSTEM  4326;

ERROR  3716  (SR005):  Can't  modify SRID  4326.  There is  at least one column depending on it.

究竟是哪一列呢?

mysql>  SELECT *  FROM INFORMATION_SCHEMA.ST_GEOMETRY_COLUMNS WHERE SRS_ID=4326\G

***************************  1.  row ***************************
               TABLE_CATALOG:  def
                TABLE_SCHEMA:  test
                     TABLE_NAME:  places
                 COLUMN_NAME:  position
                         SRS_NAME:  WGS  84 
                                SRS_ID:  4326
GEOMETRY_TYPE_NAME:  point
1  row in  set  (0,00  sec)

索引

我们可以轻松地在几何列上创建索引。

mysql>  CREATE SPATIAL INDEX position ON places  (position);
Query OK,  0  rows affected  (0,00  sec)
Records:  0  Duplicates:  0  Warnings:  0

由于此列位于SRID 4326中,因此索引也将位于SRID 4326. SRID 4326是地理位置的SRS,因此这将是地理位置索引。查询优化器将自动使用这个索引来优化与空间相关的函数掉执行(ST_Contains,ST_Within等),如果它发现这是最低成本的处理方法。所有的空间关系函数都支持地理计算。

一个可能令人惊讶的事实是,服务器仍然允许我们不必限制在单列上建索引,但是会警告这个索引永远不会被使用:

mysql>  CREATE TABLE dont_do_this  (
->  pk INT  PRIMARY KEY,
->  position POINT NOT  NULL,
->  name VARCHAR(200)
->  );
Query OK,  0  rows affected  (0,00  sec)

mysql>  CREATE SPATIAL INDEX position ON dont_do_this  (position);
Query OK,  0  rows affected,  1  warning  (0,00  sec)
Records:  0  Duplicates:  0  Warnings:  1

Warning  (Code  3674):  The spatial index on column  'position'  will not  be used by the query optimizer since the column does not  have an SRID attribute.  Consider adding an SRID attribute to  the column.

警告说明了一切。该索引将永远不会被使用。服务器允许我们仅仅为了一个原因创建索引:向后兼容mysqldump。我们应该能够从5.7加载一个mysqldump。如果在转储中存在像这样的空间索引,它们将被创建但不会使用。

MyISAM数据

值得注意的是,这只适用于InnoDB。如果我们尝试在MyISAM中的地理SRID上创建一个SRID受限列,我们会得到一个错误:

mysql>  CREATE TABLE places  (
->  pk INT  PRIMARY KEY,
->  position POINT NOT  NULL  SRID  4326,
->  name VARCHAR(200)
->  )  ENGINE=MyISAM;

ERROR  1178  (42000):  The storage engine for  the table doesn't  support geographic spatial reference systems

如果我们尝试使用笛卡尔SRS的SRID,我们可以创建表:

​mysql>  CREATE TABLE places  (
->  pk INT  PRIMARY KEY,
->  position POINT NOT  NULL  SRID  3857,
->  name VARCHAR(200)
->  )  ENGINE=MyISAM;

Query OK,  0  rows affected  (0,00  sec)

原因是MyISAM不支持地理空间索引。创建表时我们已经阻止了它。

我的建议是:将InnoDB用于所有空间数据!

相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。   相关的阿里云产品:云数据库RDS MySQL 版 阿里云关系型数据库RDS(Relational Database Service)是一种稳定可靠、可弹性伸缩的在线数据库服务,提供容灾、备份、恢复、迁移等方面的全套解决方案,彻底解决数据库运维的烦恼。 了解产品详情: https://www.aliyun.com/product/rds/mysql 
目录
相关文章
|
4月前
|
存储 SQL 关系型数据库
mysql底层原理:索引、慢查询、 sql优化、事务、隔离级别、MVCC、redolog、undolog(图解+秒懂+史上最全)
mysql底层原理:索引、慢查询、 sql优化、事务、隔离级别、MVCC、redolog、undolog(图解+秒懂+史上最全)
mysql底层原理:索引、慢查询、 sql优化、事务、隔离级别、MVCC、redolog、undolog(图解+秒懂+史上最全)
|
4月前
|
存储 关系型数据库 MySQL
MySQL数据库索引的数据结构?
MySQL中默认使用B+tree索引,它是一种多路平衡搜索树,具有树高较低、检索速度快的特点。所有数据存储在叶子节点,非叶子节点仅作索引,且叶子节点形成双向链表,便于区间查询。
160 4
|
6月前
|
缓存 NoSQL 关系型数据库
美团面试:MySQL有1000w数据,redis只存20w的数据,如何做 缓存 设计?
美团面试:MySQL有1000w数据,redis只存20w的数据,如何做 缓存 设计?
美团面试:MySQL有1000w数据,redis只存20w的数据,如何做 缓存 设计?
|
6月前
|
存储 关系型数据库 MySQL
阿里面试:MySQL 一个表最多 加几个索引? 6个?64个?还是多少?
阿里面试:MySQL 一个表最多 加几个索引? 6个?64个?还是多少?
阿里面试:MySQL 一个表最多 加几个索引? 6个?64个?还是多少?
|
4月前
|
SQL 人工智能 关系型数据库
如何实现MySQL百万级数据的查询?
本文探讨了在MySQL中对百万级数据进行排序分页查询的优化策略。面对五百万条数据,传统的浅分页和深分页查询效率较低,尤其深分页因偏移量大导致性能显著下降。通过为排序字段添加索引、使用联合索引、手动回表等方法,有效提升了查询速度。最终建议根据业务需求选择合适方案:浅分页可加单列索引,深分页推荐联合索引或子查询优化,同时结合前端传递最后一条数据ID的方式实现高效翻页。
237 0
|
2月前
|
存储 关系型数据库 MySQL
介绍MySQL的InnoDB引擎特性
总结而言 , Inno DB 引搞 是 MySQL 中 高 性 能 , 高 可靠 的 存 储选项 , 宽泛 应用于要求强 复杂交易处理场景 。
85 15
|
3月前
|
存储 关系型数据库 MySQL
在CentOS 8.x上安装Percona Xtrabackup工具备份MySQL数据步骤。
以上就是在CentOS8.x上通过Perconaxtabbackup工具对Mysql进行高效率、高可靠性、无锁定影响地实现在线快速全量及增加式数据库资料保存与恢复流程。通过以上流程可以有效地将Mysql相关资料按需求完成定期或不定期地保存与灾难恢复需求。
281 10
|
4月前
|
存储 SQL 关系型数据库
MySQL 核心知识与索引优化全解析
本文系统梳理了 MySQL 的核心知识与索引优化策略。在基础概念部分,阐述了 char 与 varchar 在存储方式和性能上的差异,以及事务的 ACID 特性、并发事务问题及对应的隔离级别(MySQL 默认 REPEATABLE READ)。 索引基础部分,详解了 InnoDB 默认的 B+tree 索引结构(多路平衡树、叶子节点存数据、双向链表支持区间查询),区分了聚簇索引(数据与索引共存,唯一)和二级索引(数据与索引分离,多个),解释了回表查询的概念及优化方法,并分析了 B+tree 作为索引结构的优势(树高低、效率稳、支持区间查询)。 索引优化部分,列出了索引创建的六大原则
123 2
|
4月前
|
SQL 存储 缓存
MySQL 如何高效可靠处理持久化数据
本文详细解析了 MySQL 的 SQL 执行流程、crash-safe 机制及性能优化策略。内容涵盖连接器、分析器、优化器、执行器与存储引擎的工作原理,深入探讨 redolog 与 binlog 的两阶段提交机制,并分析日志策略、组提交、脏页刷盘等关键性能优化手段,帮助提升数据库稳定性与执行效率。
124 0
|
5月前
|
存储 关系型数据库 MySQL
MySQL覆盖索引解释
总之,覆盖索引就像是图书馆中那些使得搜索变得极为迅速和简单的工具,一旦正确使用,就会让你的数据库查询飞快而轻便。让数据检索就像是读者在图书目录中以最快速度找到所需信息一样简便。这样的效率和速度,让覆盖索引成为数据库优化师傅们手中的尚方宝剑,既能够提升性能,又能够保持系统的整洁高效。
156 9

推荐镜像

更多