简介阿里云专有云企业版 V3.12.0 的云原生数据仓库 AnalyticDB MySQL 版用户指南是面向数据仓库运维与开发人员的官方操作手册系统讲解该大规模并行处理数据库的架构特性、适用场景与实时分析能力。文档内容覆盖产品概述、使用须知、快速入门、API 与 SDK、安全权限、故障排查和最佳实践并详解控制台登录、创建集群、设置白名单、管理账号、连接数据库及同步数据等步骤。资源包含 1 个 PDF 文件压缩包约 2.24MB方便离线查阅和全文检索目前已有 109 人学习下载。指南还附有法律声明与通用约定提醒用户经阿里云官方渠道获取并保密同时以警告、注意、说明等提示格式标注运维风险和规避建议。对新手而言可按快速入门逐步上手对有经验者也能从中获取性能调优与问题排查思路适合作为日常使用该数据仓库的核心参考。1. 专有云 V3.12.0 里的 AnalyticDB MySQL和你熟悉的公共云版差在哪先说结论在专有云企业版 V3.12.0 里维护云原生数据仓库 AnalyticDB MySQL 版最常见的翻车不是 SQL 写错而是把公共云的操作习惯直接搬进客户机房。专有云是一个隔离环境没有公网端点版本特性也比公共云收敛这决定了从建表、导数到调优的每一步都要按这套环境的节奏来。它解决的是在你的网络、你的账号和你的资源池里把一套 MySQL 协议兼容的分析型数仓真正跑起来。适合正在做专有云交付、给业务搭数仓、或者接手 V3.12.0 集群运维的工程师。看完你至少能判断一件事手里的集群慢到底该改 SQL、改表结构还是改资源参数。2. 专有云环境下的架构认知选规格前先搞清这三件事2.1 网络隔离不是一句口号它决定你所有链路怎么搭专有云部署在客户机房与公共云的物理网络完全隔离。这意味着公共云上随手能用的公网 endpoint、跨地域访问、控制台跳转在专有云里统统不存在。我帮某制造企业排查过一次导数失败应用一直连的是公共云的地址而 V3.12.0 环境里每个可用区只开放内网域名。正确做法是先拿到该环境专属的 VPC 内网 endpoint配置好白名单和安全组再让应用连接。公共云和专有云的差异可以用一张表快速对照这也是我每次接手新环境的第一份检查清单维度公共云版专有云企业版 V3.12.0连接方式公网/VPC endpoint仅专有云 VPC 内网 endpoint控制台入口官网控制台专有云独立部署控制台版本节奏新特性快速上线随专有云发行版本迭代部分能力滞后OpenAPI公共云网关专有云独立 API 网关数据通道公共云对象存储等本环境内对象存储组件这张表不用背但每次动手前要核对“我在哪一套环境里”。我排障时遇到的低级问题一半以上是拿公共云习惯套专有云产生的比如外表指向了外部存储地址、账号在两边不通用、监控告警连不上数据源。网络排查还有一个固定顺序应用主机先 ping 端点看通不通再 telnet 端口看服务在不在然后检查安全组和实例白名单最后才轮到查账号权限。顺序反了容易误判。专有云环境通常还有堡垒机或安全代理层连接串里多加一层跳板超时时间就要相应放大不要一报超时就以为是集群负载高。2.2 实例规格怎么选先把三个必填参数填对V3.12.0 控制台创建实例时核心参数是节点规格、节点数和存储空间。常见形态有两种存储计算分离的弹性形态以及本地盘预留形态。具体哪种可选以当前环境控制台实际选项为准。我一般建议先按最小可用原则建一个两节点集群跑通链路再根据实际数据量和并发扩容而不是一上来就堆大规格。节点规格里内存比 CPU 更需要关注。分析型查询大量依赖内存排序、哈希聚合两个相同核数的规格内存大一倍在高并发和复杂聚合下的表现可能差出一倍。如果业务以 BI 看板为主我通常直接把内存作为第一选择标准CPU 满足基本计算就行如果跑的是深夜批量加工CPU 核数反而更重要。节点数和存储空间可以一起估数据量在千万行级别两节点足够上亿行且查询模式复杂先按四节点起步。存储空间不要只算原始数据要留出副本、索引、未合并的小文件膨胀。我习惯用原始数据乘 1.5 到 2.0 作为初期申请值宁多勿少专有云扩容一次要走的流程比公共云重。这里要特别提醒专有云的规格变更往往需要平台管理员操作业务侧不能自助完成。所以选型时宁可多花半天评估也不要先建一个明显不够用的实例等告警再扩容。数据仓库一旦跑上业务迁移成本远高于几台机器的差价。实际选型时我还会问业务方三个问题最大单查询扫描多少行、并发查询峰值多少个、是否有定时跑批任务。单查询扫描上亿行的场景内存规格一定要给足跑批和在线查询混合的场景就要考虑资源组隔离而不是把所有任务压在一个默认资源池里。规格表填完再用这三个问题验证一遍通常不会出大偏差。2.3 账号体系分两层平台账号和数据库账号别混用专有云天然存在两层账号平台账号负责管理集群、配额、白名单这些生命周期动作ADB MySQL 实例内部还有一套数据库账号用于日常连接和 SQL 操作。常见混乱是把平台账号给业务方直连数据库权限太大不说出了问题连审计都不好定位。用户指南里的常规做法是平台账号只留给平台管理员业务侧每个应用建独立的数据库账号按库或表授权。我接手过的某项目就发生过一次事故数据组用平台账号跑任务误删了一张维表花了半天从备份恢复。之后我定的规矩是实例里只保留一个配置管理员账号其余全部按应用拆分权限最小化。连接串里也尽量不要用高权限账号避免应用被注入后直接拿到底层权限。数据库账号的密码策略在专有云里同样要注意密码过期策略、登录 IP 白名单、失败登录审计这些在专有云控制台都能配置。不要因为内网环境就觉得安全专有云机房里的运维人员、外包开发都有网络权限账号边界就是数据边界。连接数也是账号规划的一部分。ADB MySQL 实例的连接数上限与规格相关每个应用账号能建多少连接决定了 BI 工具并发上限。常见问题是业务方把连接池最大值设成 500而实例总连接上限只有 200结果应用报连接数超限。建议按应用拆分账号的同时把每个账号的连接池和实例上限对齐。3. 从建库到导数V3.12.0 的三参数建表与两条数据导入路径3.1 建库建表分布键、分区键、生命周期三个参数一次定对在 AnalyticDB MySQL 版里建表不是写完字段就行。分布键、分区键、生命周期这三个参数决定了数据物理布局建错之后改起来非常痛苦。我在带新人时经常说分析型数仓的建表七分靠物理设计三分靠 SQL 写法。下面这段 SQL 是订单事实表的常见写法覆盖了这三个关键参数。-- 建库按业务隔离数据库字符集统一使用 utf8mb4 CREATE DATABASE IF NOT EXISTS adb_orders DEFAULT CHARACTER SET utf8mb4; -- 建表订单事实表按买家ID分布按日期分区保留450天 CREATE TABLE dwd_orders ( order_id BIGINT NOT NULL COMMENT 订单ID, buyer_id BIGINT COMMENT 买家ID, seller_id BIGINT COMMENT 卖家ID, order_amount DECIMAL(18,2) COMMENT 订单金额, order_status VARCHAR(16) COMMENT 订单状态, create_time DATETIME COMMENT 下单时间 ) DISTRIBUTE BY HASH(buyer_id) PARTITION BY VALUE(DATE_FORMAT(create_time, %Y%m%d)) LIFECYCLE 450 COMMENT 订单事实表;逻辑说明DISTRIBUTE BY HASH(buyer_id) 让订单按买家 ID 哈希分布到各个节点同一买家的数据落在同一节点上按买家聚合时不需要跨节点搬数据PARTITION BY VALUE 按天生成分区查询只扫命中的日期分区LIFECYCLE 450 表示 450 天前的分区自动淘汰这条参数是控制存储成本的第一道闸门。分布键是最容易选错的一个。我见过有人拿 order_status 当分布键结果订单状态只有几种取值数据全部砸在少数几个节点上集群一半节点在忙、一半节点在看戏。选择原则高基数、常用于 JOIN 等值条件、业务上几乎不更新的列。买家 ID、用户 ID、订单 ID 都是典型的候选。分区键则相对固定绝大多数场景都按时间字段分区。注意分区粒度按天分区最灵活但分区数会很多按月分区管理简单但单分区数据量大裁剪效果差。我一般建议按天分区、按业务保留周期设置 LIFECYCLE既方便清理又能精确裁剪。参数推荐取值原因DISTRIBUTE BY高基数字段ID类数据均匀分布减少跨节点数据交换PARTITION BY时间字段按天分区裁剪精确生命周期管理简单LIFECYCLE按业务保留期如 450 天自动清理旧分区控制存储成本注意分布键建错后常见的修复是重建表并重导数据成本很高。建表前先问业务方“最常用的查询过滤条件是什么”把过滤和 JOIN 高频字段选进分布键基本不会踩大坑。3.2 两条导入路径外表批导与 DTS 增量同步数据导入是新建集群后第一个真正会卡住的环节。V3.12.0 环境里常见做法是两条路历史数据走外表批导增量数据走 DTS 同步链路。如果当前环境没有部署 DTS 组件增量部分就退化成本地定时任务加 INSERT 写入。下面这张表是我做方案选型时的判断依据。导入方式适用场景优点前提条件外表批导历史数据、离线批量吞吐高、并发可控数据文件已上传到本环境对象存储DTS 同步业务库实时增量延迟低、自动化源库开启 binlog、网络打通SQL 直写小数据量补数不需要额外通道单批次控制在合理行数外表批导的核心是一条 INSERT OVERWRITE。先通过控制台或外表 SQL 把对象存储里的文件映射成外表然后一条 SQL 导入目标表下面这个写法是最常见的形态-- 将历史订单文件导入订单事实表 INSERT OVERWRITE TABLE dwd_orders SELECT order_id, buyer_id, seller_id, order_amount, order_status, create_time FROM ext_orders_20240115;逻辑说明INSERT OVERWRITE 会覆盖目标内容重复跑同一批文件不会产生重复数据如果改成 INSERT INTO重复执行就会把相同数据再写一遍事实表出现重复行。导数的定时任务里如果用了 INSERT INTO一定要在任务侧做幂等控制。导入性能有几个可调的参数文件数量、单文件大小、是否压缩。我一般让用户把历史数据切成 128MB 到 1GB 左右的文件文件数量至少是节点数的两倍最好能到四倍这样每个节点都能分到足够多的任务并行处理。文件太小会导致调度开销占比高文件太大会让单任务跑太久失败后重试代价也大。DTS 链路的坑主要在两端源库 binlog 保留时长不够任务中断后拉不到增量位点源端频繁执行 DDL任务可能直接报错停止。我的建议是生产库表结构变更前先暂停同步任务变更完成后再启动不要指望同步工具在 DDL 期间自动兜底。专有云环境里不同组件版本依赖更明显链路涉及的每个组件是否在当前环境已部署要提前确认。3.3 第一批数据导入后立刻要做的三连查数据导完之后先别急着交付做三个检查行数对不对、分区数对不对、数据分布均不均匀。-- 检查行数与源表行数比对偏差超过1%就要查原因 SELECT COUNT(*) FROM dwd_orders; -- 检查分区生成情况确认按天分区都建立成功 SHOW PARTITIONS FROM dwd_orders;逻辑说明COUNT 比对是数据质量的第一道防线SHOW PARTITIONS 看分区列表是否完整有没有因为日期格式问题意外生成异常分区。这两个操作在导入完成后就应该立即执行而不是等到业务反馈数据对不上才回头查。数据分布检查没有固定系统表时可以跑一条按分布键分组的计数查询看结果有没有明显倾斜。比如按 buyer_id 做 COUNT如果少数几个买家的行数占了总数很大比例说明业务本身存在热点分布键需要重新评估。这一步很多人会跳过但数据倾斜是后续所有性能问题的根源值得花几分钟确认。如果行数对不上优先查两件事源文件里有没有格式错误的行被外表解析时过滤掉导入 SQL 的 WHERE 条件是不是漏了数据范围。分区列表里如果出现异常分区通常是日期字段有空值或格式不符合 DATE_FORMAT 的预期需要回到源数据清洗后再重导。这三连查做完才敢说第一批数据真正落地了。4. 查询调优与写入加速执行计划、索引边界与资源组参数4.1 慢查询先看执行计划不要急着加索引接到慢查询反馈我第一步永远不是改 SQL 或加索引而是先跑 EXPLAIN 看执行计划。分析型数仓和传统数据库不一样慢的原因往往不在 SQL 写法而在数据扫描范围和跨节点数据交换。-- 查看按时间范围聚合的查询计划 EXPLAIN SELECT buyer_id, SUM(order_amount) AS amt FROM dwd_orders WHERE create_time 2024-01-01 AND create_time 2024-02-01 GROUP BY buyer_id ORDER BY amt DESC LIMIT 100;逻辑说明EXPLAIN 不真正执行查询只输出计划。重点看三处分区裁剪是否生效计划里扫描的分区数有没有从多个变成命中范围数据扫描是否走列存聚合和排序发生在哪个算子、有没有落盘。常见误用是只看查询总耗时。两个查询耗时一样一个扫了一个月分区一个扫了全表短期没差别数据量翻倍后表现完全不同。执行计划里显示的扫描行数比返回速度更能预测未来的性能走势。如果计划里看到跨节点数据交换算子说明发生了数据重分布这时候优先考虑分布键是否合理、是否能用广播表消除交换而不是堆资源。改一个分布键和加一台机器成本完全不在一个量级。执行计划好不好前提是统计信息够新。表数据大进大出后如果没更新统计信息优化器可能拿到错误的行数估算给出次优计划。我刚接手一个集群时发现所有查询都走了广播 JOIN后来对全库刷新统计信息部分查询直降 80% 耗时。专有云版本升级或大批量导入后记得主动做一次全库统计信息刷新。4.2 索引边界什么查询值得建什么查询建了反而拖垮写入ADB MySQL 是分析型数仓默认列存储对聚合扫描非常友好。不少人从业务库转过来习惯性见 WHERE 就建索引结果写入变慢、查询没快典型的负优化。二级索引只在高过滤比点查场景下有明显收益比如 WHERE order_id 12345 这种大范围 GROUP BY 聚合查询走的是列存扫描索引完全帮不上忙。判断要不要建索引我一般看过滤比WHERE 条件筛掉的行数占比越高索引收益越大。过滤后剩余行数不足全表 5%值得建超过 20%直接全表扫描往往更快因为分析型存储的扫描速度远高于事务型。数据量小的表干脆别建索引全表扫描毫秒级完成索引反而占空间拖写入。维度表关联是另一个容易踩坑的点。几十万行级别的维度表与其让它参与跨节点 JOIN不如声明为广播表让每个节点各存一份JOIN 时不需要跨节点搬数据。代价是写入维度表时会复制多份所以只适合低频更新的场景。这个优化经常被忽略但对专有云这种资源固定的环境效果立竿见影。查询特征是否建二级索引更优方案单值点查WHERE id?建二级索引高过滤比小范围查询可建二级索引加分区裁剪大范围聚合统计不建列存扫描加分区维度表关联不建声明广播表4.3 写入加速与资源组参数把批量和并发控制住写入侧的性能优化第一原则是批量。逐行 INSERT 在分析型数仓里是性能杀手一次 INSERT 写一行会带来大量网络开销和事务开销。小规模补数应该一次写多行-- 小批量写入几十到几百行一次提交 INSERT INTO dwd_orders (order_id, buyer_id, seller_id, order_amount, order_status, create_time) VALUES (1001, 2001, 3001, 99.00, PAID, 2024-01-15 10:00:00), (1002, 2002, 3002, 199.00, PAID, 2024-01-15 10:05:00);一次 100 行以内的批量写入适合补数再多建议走外表批导。批量写也要控制频率不要让写入任务和查询任务在高峰期抢内存。并发写入任务数一般控制在节点数的两倍以内超出后收益递减反而增加锁冲突和内存压力。资源组参数是专有云运维里最容易被忽略的一层。常见做法是通过 SET ADB_CONFIG 按会话调整查询超时和内存上限-- 设置当前会话查询超时60秒 SET ADB_CONFIG query_timeout60000; -- 设置当前会话单查询内存上限8GB以当前版本支持参数为准 SET ADB_CONFIG max_execute_memory8192;query_timeout 单位毫秒可以防止慢查询长时间占着资源不释放max_execute_memory 限制单查询内存避免一个聚合任务把整个集群内存打满。这些参数按会话生效生产环境建议在资源组层面统一配置而不是依赖每个业务同学自己设置。提示专有云里多个业务共用一个实例很常见资源组隔离比公共云更重要。给重要业务单独划分资源组在线查询和定时跑批放到不同组里是避免“跑批拖垮看板”的基础手段。5. 专有云运维避坑V3.12.0 最常见的五个翻车点与排查方法5.1 查询越来越慢、磁盘却越涨越快分区治理缺失现象同一张表的查询耗时随数据量增长明显恶化控制台磁盘水位持续上升但业务方坚称“数据没增加多少”。这种矛盾很容易让人误判为集群性能不行实际上问题基本都在表结构侧。原因这类问题几乎都出在分区生命周期管理缺失。DELETE 在分析型数仓里通常只是标记删除物理文件不会立刻消失分区内小文件数量膨胀扫描开销跟着涨。没有 LIFECYCLE 的表旧分区永远占着空间查询扫描范围越来越大。解决给表补上生命周期参数确认按天分区正常生成对小文件偏多的表做分区整理定期核对磁盘水位和分区大小。我习惯每季度做一次全库分区体检把没有生命周期管理的大表找出来和业务方确认保留周期后补上治理策略。磁盘告警这种事等它响了再去查往往已经晚了。5.2 导入任务偶尔失败、重试就好资源竞争与连接数现象外表批导偶发失败报错是连接被拒或内存不足重试一次又能成功任务看起来“随机失败”。这种故障最迷惑人因为单看每次失败都是瞬时问题放在时间轴上就是资源规划问题。原因导入任务并发和节点内存峰值撞在一起触发了保护机制慢查询占满了连接数新的导入连接挤不进来。专有云环境里如果导入和在线查询共用一套资源这个问题会随着数据量增长越来越频繁。解决先看控制台的连接数曲线和内存监控确认失败时间点是否与监控尖峰重合然后控制导入并发让任务错开业务高峰给慢查询设置超时避免长期占用连接必要的话把导入和在线查询放到不同资源组。重试逻辑也要设计成有退避的不要失败后立刻重试否则只会加重资源竞争。5.3 在公共云能跑的 SQL专有云上报语法错误版本差异现象开发把公共云上验证过的建表或查询语句拿到专有云执行报函数不存在或语法错误SQL 本身逻辑没问题。比较新的字符串处理、JSON 处理函数最容易中招。原因专有云是独立发行版本功能集基于发行时的快照公共云后续新增的语法和函数不会自动同步到 V3.12.0。越是新出的语法糖越容易踩这个坑。这不一定是版本落后而是专有云本身以稳定和安全合规优先。解决以当前环境的版本说明为准不假设公共云能跑专有云就能跑。写 SQL 时用更基础的等价函数比如日期处理就用 DATE_FORMAT 这类长期稳定的写法。上线前在测试环境完整跑一遍 DDL 和查询脚本不要拿生产环境当试错环境。5.4 小版本升级后同一个 SQL 变慢统计信息与优化器现象集群做了小版本升级业务代码一行没改某条核心 SQL 从 2 秒变成 20 秒业务方第一时间怀疑升级有问题。原因升级可能改变优化器参数默认值或者让旧统计信息不再匹配新计划。分析型数仓的优化器非常依赖统计信息升级动作本身不一定有问题但升级后没有刷新统计信息是常见疏忽。解决升级后主动对核心表刷新统计信息升级前记录慢查询基线升级后对比执行计划。如果某条 SQL 确实变差先用改写或参数调整兜底再评估是否适配新优化器行为。升级窗口里一定要预留出统计信息刷新和核心查询验证的时间不要只做版本切换就收工。5.5 多个业务共用实例跑批拖垮看板资源组缺位现象数据组每天晚上跑日任务正好赶上 BI 看板活跃期看板查询大面积超时业务方投诉不断。查集群负载时发现 CPU 和内存都打满但无法区分是谁的任务在抢资源。原因所有业务共用默认资源池没有做资源组隔离大查询内存没有上限一个跑批任务就能把内存吃光其他查询全部排队。这个问题在专有云里特别常见因为实例资源是固定的不像公共云可以随时弹性扩容。解决按业务划分资源组跑批和在线查询各占独立资源在资源组层设置查询超时和内存限制。新业务接入前先登记资源组归属把这个问题前置到接入流程里比事后优化省心得多。资源组不是可选项多业务共用一个实例时这是必须做的第一件事。6. 三招验证 V3.12.0 集群是否真的健康6.1 固定 SQL 基线压测不要上线前才压测每次环境变更后跑一遍固定基线。sysbench 是通用压测工具可以直接对 MySQL 协议端点压测sysbench --db-drivermysql \ --mysql-hostadb_internal_endpoint --mysql-port3306 \ --mysql-userreport_user --mysql-passwordxxxx \ --tables8 --table-size1000000 \ --threads32 --time300 \ oltp_read_write run跑出来的 TPS 和 P95 延迟记录下来。我习惯把每次的结果存成一个文件作为容量规划和版本升级的对比基线。没有基线升级后性能变好变坏全靠感觉有了基线一次对比就能定位问题。6.2 巡检三板斧巡检不用复杂工具三件事就够控制台监控大盘看 CPU、内存、磁盘水位SHOW PROCESSLIST 看有没有长时间运行的大查询再看慢查询面板和磁盘趋势。巡检频率建议至少每周一次数据量大的环境每天看磁盘趋势。-- 查看当前连接与运行中查询重点看 Time 和 State 两列 SHOW PROCESSLIST;长时间不释放的查询通常能在 PROCESSLIST 里一眼看到Time 列异常大的会话就是排查起点。6.3 容量预估公式预估表存储可以用这个粗算公式单行大小各字段字节数之和加约 20 到 30 字节行开销乘预估行数再乘 1.5 到 2.0 的冗余系数得到至少需要的存储空间。分区数按保留天数乘日均分区数折算。容量规划是长周期动作宁可每季度校准一次也不要等磁盘告警才扩容。最后说个教训某开发者曾因为一条慢查询一口气给表加了五六个二级索引结果查询没有变快实时导入反而被拖到告警。后来撕掉索引只保留点查需要的那个导入速度恢复查询靠分区裁剪解决。这件事之后我的习惯是任何写入侧变更先看它对导入链路的副作用任何查询侧变更先看执行计划再动手。希望帮到你。本文还有配套的精品资源点击获取