简介阿里云专有云企业版V3.12.0的云原生数据仓库AnalyticDB MySQL版用户指南3.0版文档版本20200623正式分享面向专有云环境中的数据库管理员、数据架构师及大数据分析人员。这份官方文档系统讲解AnalyticDB MySQL版的核心特性与OLAP应用场景内容涵盖产品概述、使用须知、快速入门、API与SDK调用、安全权限管理、故障排查与维护、最佳实践等模块既有创建集群、设置白名单、创建账号、连接数据库等基础操作也有数据同步、性能调优和实时分析等进阶指导可帮助读者建立从环境准备到日常运维的完整知识链路。资源为单份PDF文件大小约2.24MB体积精炼便于按章节检索查阅。目前已有109人学习下载适合需要在内网或专有云环境中部署和使用AnalyticDB MySQL版的技术团队参考。1. 专有云里的 AnalyticDB MySQL别把它当成另一个 RDS 来用第一次打开专有云企业版 V3.12.0 这套用户指南的人大概率会犯同一个错把它当成 MySQL 的“云上加强版”建个表导个数据就开始写 SELECT。实际上这是 MPP 架构的分布式数仓SQL 语法兼容 MySQL但背后是列式存储、分布列、分区裁剪和 DAG 调度建表姿势、导入通道、调优方式全都不一样。这篇文章不念手册我把从选型、建库、导数据到跑慢查询、备份恢复这一路会踩的坑一次说清给要在内网或隔离环境里落地这套数仓的开发者和 DBA 一条能照着执行的路径。2. 为什么在专有云里选 AnalyticDB MySQL先看环境差异再看适用边界2.1 专有云 V3.12.0 与公共云版本的核心差异专有云企业版 V3.12.0 和公共云上的同一产品名字一样用起来却有明显差异。公共云版本的控制台、监控告警、文档更新都是跟着公共云节奏走的用户不需要关心底层资源池。专有云版本交付到客户自己的机房管控面在本地网络完全隔离无公网访问所有连接都走内网或专线。版本节奏也落后于公共云线上版本V3.12.0 是专有云交付序列里的一个稳定版本它内部包含的引擎能力以该版本配套的发布说明为准。这意味着两件事。第一你在公共云上验证过的“最新特性”在专有云里未必存在动手前先翻一遍 V3.12.0 的用户指南确认功能边界。第二运维习惯要调整扩缩容、升级、参数修改都需要走本地管控流程变更窗口要提前申请。我一般会建议客户在测试环境先跑一周的冒烟用例把公共云和专有云的行为差异列个清单再排生产迁移计划否则上线当天容易两头懵。从架构上讲AnalyticDB MySQL 版是一个 MPP 的分布式数仓计算节点之间通过高带宽网络交换数据底层是列式存储。SQL 层兼容 MySQL 协议所以 Navicat、MySQL JDBC 驱动这类工具可以直接连。兼容协议不等于内核实现一致事务隔离级别、DDL 行为、查询优化器都有自己的一套逻辑那些指望原样迁移存储过程的人往往在第一个月就翻车。2.2 适用场景和不该硬上的场景这套数仓解决的核心问题是结构化数据量大、查询复杂、需要秒级到分钟级返回分析结果。典型场景包括用户行为分析、经营报表、实时数仓的明细层和汇总层、日志结构化后的多维统计。它适合做 OLAP不适合做 OLTP。高并发小事务、行级频繁更新、强事务一致性要求这些应该继续留在业务库而不是搬进 AnalyticDB MySQL。有的团队为了减少链路硬把订单中心核心库切进来结果并发一上来就撞资源组限流最后又迁回去来回折腾大半个月。和自建的开源 MPP 数仓相比这套方案的价值在于托管和集成。自建方案要自己处理数据倾斜、节点故障恢复、备份恢复、扩缩容每一件事都是独立的运维战役。专有云版本至少把这些收敛到本地管控体系内但注意它仍然需要你理解分布列、分区键、导入通道这些数仓基本功托管不意味着无脑。我的建议是一个项目要不要上它先回答三个问题。数据量是否到了单机 MySQL 撑不住、但又不至于到 Hadoop 全家桶那么重的程度核心场景是不是以聚合查询和报表为主团队有没有人能看懂执行计划、处理数据倾斜三个都符合值得认真评估有一个不符合就再想想。2.3 账号、白名单和连接方式的内网落地专有云环境下手动建账号非常常见。管理侧创建完实例后第一件事是建业务账号而不是用初始账号对付所有人。给报表团队一个只读账号给 ETL 团队一个读写账号给 DBA 保留管理账号权限边界一开始就划清楚后面省很多事。连接层面专有云没有公共云那种公网安全组走的是内网访问控制和 IP 白名单比如只允许 ETL 服务器所在网段访问。# 用 MySQL 客户端验证连通性专有云内网环境推荐指定库名并严格限制超时 mysql -h 内网VIP -P 端口 -u 账号 -p密码 -D database \ --default-character-setutf8mb4 --connect-timeout5 -e SELECT version();这段命令里有几个参数值得说明。内网VIP是本地管控分配的虚拟 IP不要用节点 IP因为计算节点可能扩缩容变化--connect-timeout5是为了快速失败避免网络不通时客户端长时间挂起-D指定默认库避免连上后还要切库。能返回version()就说明网络层通了。若超时优先查白名单是否包含当前机器 IP再看服务端口是否被防火墙拦截。3. 从建实例到第一批数据入库分布列选错就翻车3.1 实例规格怎么定节点数、存储和 CPU 的关系实例规格往往是最容易被拍脑袋的部分。我见过一个预算充足的团队把节点数拉满结果跑了一个月发现 CPU 利用率不到 10%也见过为了省钱上了最小规格结果一个大查询把资源池打满影响线上报表。确定规格不能只看数据总量要看查询复杂度和并发。最小可用配置往往是数据量除以单节点可承载容量再乘一个并发系数但这个系数只有压测能给你准确值。单节点选择的参考维度大致如下CPU 核数决定单查询的执行并行度内存决定排序和哈希关联的容量存储空间决定能装多少数据。节点规格适用负载常见表现小规格低 CPU / 小内存明细查询少、报表简单大聚合容易内存不足被临时落盘拖慢中等规格均衡型常规报表 中等并发多数场景够用注意大查询排队大规格高 CPU / 大内存复杂关联、宽表聚合执行计划并行度高成本也明显更高我惯用的做法是先按目标业务表的行数估算总存储需求再留 30% 冗余然后按这个存储量反推最小节点数上线前用压测工具模拟真实查询观察 CPU 和内存水位再决定是否扩容。不要忘了专有云扩缩容要排窗口所以前期宁可多申请一点也不要上线后发现不够。3.2 建库建表分布列、分区键和索引的取舍建表是整个使用过程中最不能随意的一步。在 AnalyticDB MySQL 里建表要明确指定分布列和分区键这两个选择直接决定了查询是走并行扫描还是把所有数据拉到单节点。分布列选择的第一原则是“高基数且均匀”比如用户 ID、订单 ID。选性别这种低基数列做分布列所有男性用户的数据可能落在同一批节点上查询时一半节点闲着另一半跑满这就是数据倾斜。分区键的选择服务于“裁剪”。绝大多数数仓查询都带时间范围用日期字段做分区键查询只扫需要的分区而不是全表扫描。有人建表时图省事不设分区结果一个月后每条查询都慢三倍血泪教训。-- 建库时指定字符集避免后续写入中文乱码 CREATE DATABASE IF NOT EXISTS ads_warehouse DEFAULT CHARACTER SET utf8mb4; -- 建表分布列选 user_id分区键选 stat_date CREATE TABLE IF NOT EXISTS ads_warehouse.user_daily_stats ( user_id BIGINT NOT NULL COMMENT 用户ID, stat_date DATE NOT NULL COMMENT 统计日期, order_cnt INT DEFAULT 0 COMMENT 下单数, order_amount DECIMAL(12, 2) DEFAULT 0.00 COMMENT 下单金额, create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 入库时间 ) DISTRIBUTE BY HASH(user_id) PARTITION BY RANGE(stat_date) ( PARTITION p20250101 VALUES LESS THAN (2025-01-01), PARTITION p20250201 VALUES LESS THAN (2025-02-01), PARTITION p20250301 VALUES LESS THAN (2025-03-01) );这段建表 SQL 里有三个关键设计。DISTRIBUTE BY HASH(user_id)表示按用户 ID 哈希分布到各节点这样同一用户的多次查询大概率只在同一个或少数几个节点扫描关联查询也能本地完成。PARTITION BY RANGE(stat_date)按日期范围分区写入时根据日期自动路由查询时只扫命中分区。分区定义里用VALUES LESS THAN划定边界新增分区需要手动添加忘记加会导致新数据写入失败——这是非常常见的线上事故点。还要注意表注释和字段注释在生产环境尽量写全。数仓表越到后期越依赖元数据没人记得当初“order_cnt”是含退款还是不含退款注释就是最后的说明书。3.3 数据导入外表加载和批量写入的正确姿势数据导入是最容易被低估的环节。最常见的翻车现场是团队用 INSERT 一条条往表里写数据写法上完全没问题性能上就是灾难。AnalyticDB MySQL 的最佳路径是攒批后通过外表或专用加载通道批量写入。专有云环境常用的是先在对象存储或本地文件系统放好数据文件然后创建外表映射再一次性写入目标表。-- 1. 创建外表映射到数据文件所在路径 CREATE TABLE IF NOT EXISTS ads_warehouse.user_daily_stats_ext ( user_id BIGINT, stat_date DATE, order_cnt INT, order_amount DECIMAL(12, 2) ) USING csv OPTIONS ( file.path oss://bucket-name/data/user_daily_stats/, file.escape , file.quote , file.delimiter ,, file.skip.header.line.count 1 ); -- 2. 批量写入目标表注意这里是覆盖写还是追加写 INSERT OVERWRITE TABLE ads_warehouse.user_daily_stats SELECT * FROM ads_warehouse.user_daily_stats_ext;外表映射里面向对象存储路径的oss://bucket-name是专有云内部的存储路径实际地址以本地环境配置为准。file.escape和file.quote是很多人忽略的参数CSV 字段里如果包含逗号或引号不设置好解析规则会出现字段错位导完数据再查就发现金额算错了。file.skip.header.line.count1表示跳过首行表头没有表头的文件不要设置否则丢第一条数据。INSERT OVERWRITE是覆盖写同名分区会先清后写适合全量刷新如果业务要做增量应该用INSERT INTO追加。我在生产中建议把这两条路径拆成两个不同任务全量初始化走 OVERWRITE每日增量走 INTO避免误操作清掉历史数据。整批写入完成后立刻执行SELECT COUNT(*)对比源文件行数并抽查几个关键分区的汇总值这一步是成本最低的验收手段。4. 查询性能调优读执行计划、调四个参数4.1 从 EXPLAIN 看 DAG哪些节点在拖慢查询把慢查询拉出来第一步永远是看执行计划而不是盲目加节点。AnalyticDB MySQL 的 EXPLAIN 会把一个查询拆成多个算子节点最需要注意的是两类节点一类是数据交换节点shuffle一类是聚合或关联节点。数据交换意味着数据要在节点间搬移搬移的量越大查询越慢。-- 查看执行计划重点关注 Exchange 和 Agg 算子的数据量 EXPLAIN SELECT stat_date, COUNT(DISTINCT user_id), SUM(order_amount) FROM ads_warehouse.user_daily_stats WHERE stat_date 2025-01-01 GROUP BY stat_date;执行计划输出里如果聚合之前有大规模的 Exchange 节点说明分布列没有干活数据被拉到同一个节点做最终聚合。此时要先确认 GROUP BY 的分组键和分布列的关系如果分组键本身就是分布列很多聚合可以在本地完成计算量会小一个量级。COUNT(DISTINCT) 是另一个嫌疑点它需要全局去重数据量大时非常耗内存能用 COUNT 加 GROUP BY 改写就改写或者用近似去重函数替代。看执行计划还有个经验关注每个算子输出的行数行数没降下来的过滤条件大概率没被下推。比如 WHERE 条件里写了分区字段但计划里仍扫了全部分区那就是分区裁剪没生效要检查分区字段的类型是否和查询条件一致日期字段传成字符串常导致裁剪失效。4.2 四个可抄作业的调优参数在调优阶段与其漫无目的地翻文档不如先把下面四个参数检查一遍。这套顺序是我在多个项目里反复用过的按部就班操作就能定位大部分慢查询。第一个参数是查询超时时间。专有云环境里默认超时可能比较保守ETL 里的长查询容易被中途掐断。把它调大后需要观察是否还有查询因超时失败如果超时失败率明显下降说明不是性能问题而是阈值设置问题。第二个参数是查询内存上限。大聚合或排序类查询对内存敏感上限不够时引擎会把中间结果落盘落盘一多性能直线下跌。这个参数和节点内存规格要配套设置得比物理内存还大没有意义反而会增加 OOM 风险。第三个参数是查询并发数。并发设得太高多个大查询互相争抢 CPU 和内存每个查询都慢设得太低并发一上来就排队。我一般先跑一个基准查询测单查询耗时再逐步增加并发观察耗时拐点拐点对应的并发就是比较合理的工作点。第四个参数是单个查询的扫描量限制防止有人不小心写了个全表扫描把资源池打爆。设置后超过阈值查询直接报错而不是默默跑十分钟。这在多人共用环境的治理上非常有用相当于给每个查询戴上安全帽。参数调整方向主要影响查询超时时间调大长查询不被误杀查询内存上限调大避免中间结果落盘查询并发数先降后升控制资源争抢扫描量限制调小拦截全表扫描调整完参数记得用同一条查询做前后耗时对比。参数调优最忌讳一次性改多个出了问题不知道是哪个改动引起的一次只动一个记录基线再对比。4.3 慢查询排查顺序真遇到慢查询我建议按固定顺序排查而不是东看一眼西摸一下。第一步看查询是不是在排队如果集群整体繁忙单条查询再优化也提不上速。第二步看执行计划找 Exchange 节点和数据倾斜。第三步看表的统计信息过期的统计信息会让优化器选错执行计划更新统计信息后查询路径可能完全不同。第四步看数据分布是否倾斜某个节点的数据量明显高于其他节点需要重设分布列或拆分热点键。这个顺序能覆盖绝大多数慢查询场景剩下的才是真正的引擎级问题。5. 常见问题避坑这些坑我都踩过你别再踩5.1 分布列选错导致数据倾斜查询节点忙闲不均现象同一个查询每次执行某个节点的 CPU 明显高于其他节点任务整体耗时就卡在这个节点上。 原因分布列基数太低比如按地区分布某个地区数据量占一半所有针对这个地区的查询都压在同一个节点上。 解决把分布列改为高基数字段比如用户 ID 或订单 ID如果业务必须按地区过滤可以改成复合分布列或者对热点键做加盐处理把热点数据打散到多个节点后再聚合。5.2 逐行 INSERT 导致写入性能断崖现象用程序循环执行单行 INSERT每秒只能写几十行数据一多直接等死人。 原因每条 INSERT 都是一次独立的事务和网络往返分布式数仓对单行写入的代价远高于批量写入大量小事务还会争抢日志和锁。 解决改攒批写入程序里把数据攒到一定条数或时间窗口后一次提交或者干脆走外表加载通道。这里特别提醒攒批大小需要做一次简单测试批次太大容易触发内存问题批次太小提升有限一般从 1000 条每批起步观察。5.3 备份恢复后数据校验不一致现象做完备份恢复SELECT COUNT(*)对不上业务报表数据有出入。 原因备份恢复不是持续同步恢复时间点之后写入的新数据不会出现在恢复结果里另一个常见原因是备份过程中目标表还在写入数据文件状态不一致。 解决每次恢复完不要只对总数要按分区核对数据范围和抽样明细恢复前暂停写入任务恢复后开启应用前先做一次完整校验。把“恢复演练”当成定期任务不要等到真出事故才第一次试。5.4 长查询跑了一半连接被断开现象ETL 的复杂查询执行几分钟后报连接丢失重跑可能就成功了也可能继续失败。 原因连接池的空闲超时设置得太短或者服务端会话超时把长任务连接回收了。查询本身没问题是连接层的配置在捣乱。 解决连接串里显式配置sessionVariableswait_timeout86400之类的参数或调整连接池的maxLifetime和idleTimeout确保长查询期间的会话不被回收。这类问题排查起来的难点在于它没有稳定复现路径跑一个小时才出现一次非常折磨人。5.5 外表导入时文件格式细节翻车现象外表导入后某些行的金额为空或者日期字段全是 0000-00-00源头文件明明没问题。 原因CSV 文件里的引号、转义符和日期格式没有在外表参数里配置好。特别常见的是日期字段格式为2025/01/01而引擎默认期望2025-01-01解析失败后静默写入默认值。 解决先用一小段样例文件建外表并查询确认字段解析正确后再全量导入日期字段在源端先统一成标准格式。这一步是最容易被忽略的但它的排查成本和结果影响完全不匹配提前试跑 10 行数据就能验证所有格式问题。6. 进阶资源组隔离 冷热分层把数仓稳稳跑起来环境稳定运行一段时间后下一步要考虑的是多业务共存时的管理问题。一个数仓实例上往往同时跑着 ETL 和报表查询ETL 任务重、时间长报表查询要求响应快。如果两者不做隔离ETL 一跑报表就卡业务方就开始投诉。资源组隔离是解决这个问题的标准手段。给 ETL 和报表各建一个资源组通过账号或查询标签绑定到不同资源组两个负载各自使用独立的内存和并发配额互不挤占。做完隔离后报表慢查询的处理思路就变了先看对应资源组的负载情况而不是下意识怀疑集群整体资源不够。-- 查询资源组的实时负载确认是否存在排队 SELECT resource_group_name, running_queries, queued_queries FROM information_schema.resource_groups;查询结果里queued_queries就是排队的查询数这个数字持续大于 0说明资源组的配额不够要么扩容资源组要么拆分业务负载。这一步非常有用它把玄学式的“感觉集群有些慢”变成了可以量化的排队指标。冷热分层解决的是存储成本问题。数仓里最占空间的往往是几个月前、几乎不再被查询的历史明细。做法是把这些数据定期挪到单独的归档表或冷分区从热查询路径里摘出去热表扫描量直接缩小一个量级。实现方式可以是定时任务按分区导出并清理保留最近三个月热分区其余归档到低成本存储。运行一段时间后你会明显感觉到报表查询的响应更稳定了因为扫描的数据量少了。我最后想分享一个教训以前在一个项目里我为了让报表查询更快连续调了三天查询参数效果都不明显后来停下来专门看扫描行数发现一张核心大表三年数据全堆在一起每次查询都在扫历史。然后花了一个晚上做冷热分离第二天查询速度直接提升了接近一倍。很多所谓性能问题根源不在引擎而在数据组织方式。先把数据组织理顺再动参数顺序反过来只会白熬夜。这是这套数仓最值得投入精力的地方也是我从那次实践之后一直坚持的做事顺序。希望帮到你。本文还有配套的精品资源点击获取