AnalyticDB MySQL-表和索引与MySQL的差异

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS PostgreSQL,高可用系列 2核4GB
云数据库 RDS MySQL,高可用系列 2核4GB
简介: AnalyticDB MySQL在语法上兼容MySQL,但是它的技术架构不同于MySQL,表和索引也和MySQL差异较大,这篇文章列出了这些差异,在使用AnalyticDB MySQL创建表时可以参考一下。

     AnalyticDB MySQL版是阿里云的海量数据实时高并发在线分析数据仓库,语法完全兼容MySQL,在使用AnalyticDB MySQL时表面上就和使用MySQL一样,建表时也可以使用MySQL的建表语句。但是,这个只是表面现象, AnalyticDB MySQL在技术架构上和MySQL完全不同,在表和索引的使用上也和MySQL差异较大,如果忽视这些差异,将它当作MySQL来使用,可能会较大为问题。

1 AnalyticDB MySQL中的表

      AnalyticDB MySQL版支持复制表和普通表两种类型。复制表也可以称为广播表,会在集群的每个节点存储一份数据,对应与数据仓库中的维度表,因此复制表的数据量不宜太大,阿里的建议每张复制表存储的数据不超过2万行。

      AnalyticDB MySQL的普通表和MySQL数据库的普通表的概念不同,在AnalyticDB MySQL里,普通表实际上是分片表,AnalyticDB MySQL的建表语法同MySQL兼容,如果使用MySQL的建表语法创建了一张表,在表有主键的情况下,AnalyticDB MySQL会以主键作为分片键,如果没有主键,如果MySQL表不含有主键,AnalyticDB MySQL版将添加一个__adb_auto_id__字段作为主键和分布键。

      假设用户用下面的MySQL的建表语句在AnalyticDB MySQL建了一张表

CREATETABLE t (c1 bigint, c2 int, c3 varchar, PRIMARY KEY(c1,c2));    Query OK,0 rows affected (2.37 sec)

      在AnalyticDB MySQL中查看表的定义是下面这个样子

SHOW CREATETABLE t;+-------+-------------------------------------------------------------------------------------------------------------------------------+|Table|CreateTable|+-------+-------------------------------------------------------------------------------------------------------------------------------+| t     |CreateTable `t` (     `c1` bigint,     `c2` int,     `c3` varchar,     primary key (c1,c2)) DISTRIBUTED BY HASH(`c1`,`c2`) INDEX_ALL='Y'|+-------+-------------------------------------------------------------------------------------------------------------------------------+1 row inset(0.04 sec)

     从上面的建表语句可以看到,在AnalyticDB MySQL中,分片(使用分布键)是必须的,强制的,除非使用复制表,分区则是用户自由定制的。AnalyticDB MySQL中,分布

采用的是哈希算法,每张表只支持一个分布键,这个是显而易见的,因为AnalyticDB MySQL使用分布键在集群内的节点上分布数据,在实际分布数据时,只能选择一种分布方式,多个分布键毫无意义。在选择分布键时,不建议选择日期、时间和时间戳类型,而应该选择交易ID、设备ID、用户ID(具有业务特征的),如果此类的键,可以选择自增键。这样选择的目的是将可能利用AnalyticDB MySQL的节点进行分布是计算,举一个简单的例子,我们要查询一批用户的一段时间内数据,首先想到的是查询是以每个用户为单位来区分的,我们希望把每个用户的查询分布到不同的节点上,而不是希望每个时间段的数据的查询分布到不同的节点上。在分布键的选择上,还要注意优先选择查询频率高的、join的键作为分布键。

     另一个值得注意的地方是,在AnalyticDB MySQL中,表的分片数是自动决定的,用户不可以手动设置一个表的分片数,一个表的具体分片数是由数据库的版本和集群的配置决定的,配置越高,表的分片树越多。

     在分布的基础上,可以再对表进行分区,当一个分片的数据库太大影响查询性能时,就需要对分片进行分区。这里的分区类似mysql数据库中范围分区,最常见的是时间作为分区键。

      分区的另外的好处是可以利用AnalyticDB MySQL的LIFECYCLE N特定以及冷热特性,超过生命周期的分区会被自动删除,也可以设置冷热分区的比例。二级分区的数据应该维持静态,数据不应在二级分区之间内移动,如果二级分区频繁更新,可能是分区键选择的不合理。

     表的主键,主键可以作为每一条记录的唯一标识。在创建表时,通过PRIMARY KEY来定义主键,在AnalyticDB MySQL中,只用定义了主键表才支持数据更新操作,包括更新和删除。

     主键可以是单个字段或多个字段的组合,同时主键必须包含分布键和分区键,考虑到性能,分布键和分区键尽可能放到主键的前部。

     在表上也可以创建聚集索引,每个表仅仅支持创建一个聚集索引。

     下面用一个官网上的例子说明一下,

CREATETABLE customer (        customer_id bigintNOTNULL COMMENT '顾客ID',        customer_name varcharNOTNULL COMMENT '顾客姓名',        phone_num bigintNOTNULL COMMENT '电话',        city_name varcharNOTNULL COMMENT '所属城市',        sex intNOTNULL COMMENT '性别',        id_number varcharNOTNULL COMMENT '身份证号码',        home_address varcharNOTNULL COMMENT '家庭住址',        office_address varcharNOTNULL COMMENT '办公地址',        age intNOTNULL COMMENT '年龄',        login_time timestampNOTNULL COMMENT '登录时间',        PRIMARY KEY (login_time, customer_id, phone_num))        DISTRIBUTED BY HASH(customer_id)        PARTITION BY VALUE(DATE_FORMAT(login_time,'%Y%m%d')) LIFECYCLE 30        COMMENT '客户信息表';

     表customer采用customer_id作为分布键,以login_time作为分区键,主键必须包含分区键和分布键,这里选择login_time, customer_id, phone_num,分布键和分区键尽可能放到主键的前部和分布键放在主键靠前的部分,分区以天为单位,同时设置了LIFECYCLE特性,超过30天的分区会被自动删除。

2 自适应索引

      AnalyticDB MySQL的玄武存储引擎采用了自适应列级自动索引技术,针对字符串、数字、文本、JSON、向量等列类型都会自动创建索引,在数据库中创建一张表后用show indexes from <表名>查询,

      可以看到每个列上都有一个索引,这些索引是AnalyticDB MySQL自动创建的,AnalyticDB MySQL可以做到列级索引任意维度组合检索、多路渐进流式归并,大幅提升了数据过滤性


相关实践学习
阿里云云原生数据仓库AnalyticDB MySQL版 使用教程
云原生数据仓库AnalyticDB MySQL版是一种支持高并发低延时查询的新一代云原生数据仓库,高度兼容MySQL协议以及SQL:92、SQL:99、SQL:2003标准,可以对海量数据进行即时的多维分析透视和业务探索,快速构建企业云上数据仓库。 了解产品 https://www.aliyun.com/product/ApsaraDB/ads
相关文章
|
3月前
|
存储 SQL 关系型数据库
mysql底层原理:索引、慢查询、 sql优化、事务、隔离级别、MVCC、redolog、undolog(图解+秒懂+史上最全)
mysql底层原理:索引、慢查询、 sql优化、事务、隔离级别、MVCC、redolog、undolog(图解+秒懂+史上最全)
mysql底层原理:索引、慢查询、 sql优化、事务、隔离级别、MVCC、redolog、undolog(图解+秒懂+史上最全)
|
3月前
|
存储 关系型数据库 MySQL
MySQL数据库索引的数据结构?
MySQL中默认使用B+tree索引,它是一种多路平衡搜索树,具有树高较低、检索速度快的特点。所有数据存储在叶子节点,非叶子节点仅作索引,且叶子节点形成双向链表,便于区间查询。
113 4
|
5月前
|
存储 关系型数据库 MySQL
阿里面试:MySQL 一个表最多 加几个索引? 6个?64个?还是多少?
阿里面试:MySQL 一个表最多 加几个索引? 6个?64个?还是多少?
阿里面试:MySQL 一个表最多 加几个索引? 6个?64个?还是多少?
|
3月前
|
存储 SQL 关系型数据库
MySQL 核心知识与索引优化全解析
本文系统梳理了 MySQL 的核心知识与索引优化策略。在基础概念部分,阐述了 char 与 varchar 在存储方式和性能上的差异,以及事务的 ACID 特性、并发事务问题及对应的隔离级别(MySQL 默认 REPEATABLE READ)。 索引基础部分,详解了 InnoDB 默认的 B+tree 索引结构(多路平衡树、叶子节点存数据、双向链表支持区间查询),区分了聚簇索引(数据与索引共存,唯一)和二级索引(数据与索引分离,多个),解释了回表查询的概念及优化方法,并分析了 B+tree 作为索引结构的优势(树高低、效率稳、支持区间查询)。 索引优化部分,列出了索引创建的六大原则
|
4月前
|
监控 关系型数据库 MySQL
DTS实时同步进阶:MySQL到AnalyticDB毫秒级ETL管道搭建
本方案采用“Binlog解析-数据清洗-批量写入”三级流水线架构,实现MySQL到AnalyticDB的高效同步。通过状态机解析、内存格式转换与向量化写入技术,保障毫秒级延迟(P99&lt;300ms)、50万+ TPS吞吐及99.99%数据一致性,支持高并发、低延迟的数据实时处理场景。
120 10
|
4月前
|
存储 关系型数据库 MySQL
MySQL覆盖索引解释
总之,覆盖索引就像是图书馆中那些使得搜索变得极为迅速和简单的工具,一旦正确使用,就会让你的数据库查询飞快而轻便。让数据检索就像是读者在图书目录中以最快速度找到所需信息一样简便。这样的效率和速度,让覆盖索引成为数据库优化师傅们手中的尚方宝剑,既能够提升性能,又能够保持系统的整洁高效。
127 9
|
5月前
|
机器学习/深度学习 关系型数据库 MySQL
对比MySQL全文索引与常规索引的互异性
现在,你或许明白了这两种索引的差异,但任何技术决策都不应仅仅基于理论之上。你可以创建你的数据库实验环境,尝试不同类型的索引,看看它们如何影响性能,感受它们真实的力量。只有这样,你才能熟悉它们,掌握什么时候使用全文索引,什么时候使用常规索引,以适应复杂多变的业务需求。
113 12
|
3月前
|
运维 算法 机器人
阿里云AnalyticDB具身智能方案:破解机器人仿真数据、算力与运维之困
本文将介绍阿里云瑶池旗下的云原生数据仓库AnalyticDB MySQL推出的全托管云上仿真解决方案,方案采用云原生架构,为开发者提供从开发环境、仿真计算到数据管理的全链路支持。
|
19天前
|
存储 人工智能 关系型数据库
阿里云AnalyticDB for PostgreSQL 入选VLDB 2025:统一架构破局HTAP,Beam+Laser引擎赋能Data+AI融合新范式
在数据驱动与人工智能深度融合的时代,企业对数据仓库的需求早已超越“查得快”这一基础能力。面对传统数仓挑战,阿里云瑶池数据库AnalyticDB for PostgreSQL(简称ADB-PG)创新性地构建了统一架构下的Shared-Nothing与Shared-Storage双模融合体系,并自主研发Beam混合存储引擎与Laser向量化执行引擎,全面解决HTAP场景下性能、弹性、成本与实时性的矛盾。 近日,相关研究成果发表于在英国伦敦召开的数据库领域顶级会议 VLDB 2025,标志着中国自研云数仓技术再次登上国际舞台。
121 0
|
2月前
|
存储 人工智能 分布式计算
数据不用搬,AI直接炼!阿里云AnalyticDB AI数据湖仓一站式融合AI+BI
阿里云瑶池旗下的云原生数据仓库AnalyticDB MySQL版(以下简称ADB)诞生于高性能实时数仓时代,实现了PB级结构化数据的高效处理和分析。在前几年,为拥抱大数据的浪潮,ADB从传统数仓拓展到数据湖仓,支持Paimon/Iceberg/Delta Lake/Hudi湖格式,为开放的数据湖提供数据库级别的性能、可靠性和管理能力,从而更好地服务以SQL为核心的大规模数据处理和BI分析,奠定了坚实的湖仓一体基础。

推荐镜像

更多