简介面向云数据仓库运维人员、数据分析师与架构师的《阿里云专有云企业版V3.12.0云原生数据仓库AnalyticDB MySQL版用户指南3.0》对应20200623文档版本重点解决专有云环境下OLAP集群的部署认知、日常使用与性能优化问题。压缩包仅含1个PDF文件大小约2.24MB便于离线查阅和内部培训归档。指南内容覆盖产品概述、法律声明与通用约定并给出控制台登录、新建数据库集群、设置白名单、创建账号与数据库、连接集群、申请外网地址、同步数据等快速入门路径同时涉及API与SDK调用、安全权限管理、故障排查维护和最佳实践。已有110人学习适合需要系统理解AnalyticDB MySQL版操作边界、排查思路与调优要点并希望以官方文档作为实施参考的技术人员。1. 拿到这份 V3.12.0 用户指南先搞清楚它到底能替你做哪些决策不少团队在专有云环境里第一次接触 AnalyticDB MySQL 版习惯先点控制台走一遍流程结果往往卡在三个地方白名单没放通、外网地址没申请、高权限账号建不出来。这份专有云企业版 V3.12.0 配套的用户指南文档版本 20200623真正值钱的部分不是前面那几页产品介绍而是它把建集群、连库、灌数据、调优、排障这几条链路上的输入参数和边界条件都写死了。它适合三类人刚接手专有云数据仓库的 DBA、要把业务从 MySQL 迁到分析型的后端开发以及做 BI 报表、需要提前确认 SQL 兼容范围的数据开发。下面按我实际落地的顺序拆先开服再连库然后读 SQL 手册最后是踩坑和调优。2. 从空集群到第一条 SQL开服流程的六个卡点专有云环境和公有云最大的差别是控制台入口、资源池划分、网络规划全部由平台侧交付你拿到的是一套已经划好的资源而不是一个可以随便点选的购物车。所以开服这一步不能照着公有云教程抄得按交付清单来。指南第 3 章的快速入门把顺序列得很清楚登录控制台、新建集群、设白名单、建账号、建库、连接、按需申请外网地址、同步数据。顺序本身不难难的是每一步背后那几个必填项到底怎么定。2.1 规格、副本与网络建集群前必须先算清楚的三笔账新建集群页面上最容易被草率填掉的是规格。分析型数据库是 MPP 架构一条查询会被拆到多个节点并行执行节点数基本决定了并行度和可用的计算内存单节点规格决定单机处理能力。常见的误判是拿 TP 业务的 QPS 去推规格结果上线后发现慢在扫描和聚合上跟并发数关系不大。我的经验是先按「单条查询需要扫描的数据量 ÷ 单节点可承载的扫描量」估节点数再用并发数做修正别反过来。副本数是第二笔账。多副本影响可用存储和故障时的数据可靠性副本越多同样原始数据占用的物理空间越大。生产集群一般不会只配一份测试环境可以压到最小这一点在指南的「变更配置」一节里有对应说明但变更是有窗口和代价的前期估错后期补很麻烦。第三笔是网络。专有云里集群要挂到指定的 VPC 和交换机下业务系统如果不在同一个 VPC就得提前规划打通方式而不是等连不上再回头改。这一项在控制台上只是一个下拉框实际影响的是后面所有连接配置。参数常见取值落地时的判断依据资源池 / 可用区由平台侧分配专有云没有自选地域的概念按交付单填节点数示例4 / 8 / 16由扫描量和并发共同决定不要只看 QPS单节点规格示例8 核 64 GB聚合类查询吃内存别只堆 CPU副本数2 或 3生产建议不低于 2测试可压到 1VPC / 交换机与业务同 VPC跨 VPC 要提前申请打通集群名示例adb_prod_01全局唯一命名带上环境标识集群创建是个分钟级操作界面上会有进度状态。这个阶段最容易犯的错是集群还没到「运行中」就去连然后怀疑网络有问题。我的习惯是建完先不急着连把下面三样东西一次性准备好白名单、账号、库名。2.2 白名单、账号、库顺序反了就要返工这三步的依赖关系是硬的白名单决定谁能连进来账号决定连进来之后是谁库决定这个账号能看到什么。很多人先建库再想账号结果发现建库本身就需要一个有权限的账号只能回头补。白名单在指南里对应 3.3 节填的是 CIDR 格式的网段不是单个 IP。常见写法是业务服务器的网段加 32 位掩码比如10.20.30.0/24表示整个网段放通。这里有个容易被忽略的点如果你从办公网直连办公网的出口 IP 往往是动态的写死一个 IP 过两天就失效表现为「昨天还能连今天连不上」。稳妥做法是走跳板机或固定出口别把办公网 IP 直接塞进白名单。账号分两类高权限账号和普通账号。高权限账号一般通过控制台创建权限覆盖整个集群用来建库、建普通账号、做运维操作普通账号按库或按表授权给业务和 ETL 用。指南第 8 章的权限模型把这套关系画得很清楚核心就一句话高权限账号不要给应用用它是运维身份不是业务身份。建库用高权限账号执行语法和 MySQL 基本一致-- 用高权限账号登录后执行 CREATE DATABASE ads_demo; -- 建一个只读的业务账号密码按平台密码策略设置 CREATE USER bi_reader% IDENTIFIED BY ChangeMe_2020; -- 只给这张库的查询权限够用就行别图省事给 ALL GRANT SELECT ON ads_demo.* TO bi_reader%; -- 授权后必须刷新否则新权限不生效 FLUSH PRIVILEGES;这段里有两个参数值得单独说。%表示允许从任意主机登录实际生产中建议收窄到具体网段比如10.20.30.%这样即便密码泄露攻击面也小一圈。GRANT SELECT ON ads_demo.*里的*是库级通配如果只想给某几张表写成ads_demo.ads_order这样的表级授权更细。授权语句在指南 11.6 节有完整语法包括WITH GRANT OPTION这类会带来权限扩散风险的选项我的建议是业务账号一律不加。还有一个细节账号名和库名在建好之后改起来很麻烦RENAME USER虽然支持但涉及已有连接和授权记录生产上基本等于重建。所以命名规则最好在开服前就定下来比如业务域_用途的格式。2.3 外网地址与连接串什么时候才值得申请指南 3.7 节单独讲了申请外网地址这个功能存在的意义是让不在 VPC 内的客户端比如你本机的图形化工具能连进来调试。它带来的是实打实的暴露面所以我的原则是默认不申请需要时申请用完释放。内网连接串的形态是主机地址:3306端口固定主机地址在集群详情页能看到。走内网的好处不只是安全延迟和带宽也稳定得多。跑批量同步任务时如果用外网地址很容易出现跑到一半超时、重试、再超时的情况最后数据对不上排查半天发现是网络抖。外网地址申请下来之后连接串格式和内网一样只是主机名不同。这里有个容易翻车的点申请了外网地址不等于白名单自动放通你还是得把客户端出口 IP 加进白名单否则一样连不上。这个顺序在文档里是分开写的实际操作时一定要连着做。3. 连接 AnalyticDB MySQL驱动、连接池与图形客户端这一章是实操密度最高的部分。AnalyticDB MySQL 版兼容 MySQL 协议这句话的含义是「大部分 MySQL 客户端和驱动能直接连」但「兼容」不等于「完全一致」驱动版本、连接参数、字符集、超时设置这几处该改还得改。指南第 4 章按语言和工具分别给了示例我按实际用下来的顺手程度重新组织一下。3.1 命令行与 Python最小可用配置怎么填命令行是最快的验证手段连不上就先别写代码用命令行试一次能排除掉一大半驱动层的问题# -h 填集群连接串里的地址-P 固定 3306-D 直接切到目标库 # --default-character-set 显式指定避免中文乱码 mysql -h adb-proxy.internal -P 3306 -u adb_root -p -D ads_demo \ --default-character-setutf8mb4几个参数的含义值得记一下。-P是大写指端口小写-p指密码两个一起写错的人不少表现是提示「Access denied」而不是连接失败容易误判成账号问题。--default-character-setutf8mb4建议每次显式带上专有云环境的服务端字符集由部署时决定客户端不指定的话遇到中文和 emoji 就会出乱码或者插入截断。Python 侧用 pymysql 就够关键在超时参数import pymysql conn pymysql.connect( hostadb-proxy.internal, # 内网地址批量任务不要走外网 port3306, useretl_user, password******, databaseads_demo, charsetutf8mb4, connect_timeout5, # 建连超时要小于上层重试间隔 read_timeout120, # 大聚合查询适当放大否则会 Read timeout autocommitTrue, # 分析型写入多为批量按需开启 ) with conn.cursor() as cur: cur.execute(SELECT COUNT(*) FROM ads_order WHERE dt 2020-06-01) print(cur.fetchone())connect_timeout给 5 秒是有讲究的。如果上层框架的重试间隔是 3 秒而你这里给了 30 秒那么一次网络抖动会拖住线程池三十秒重试策略形同虚设。read_timeout反过来要放大分析型查询跑几十秒很正常设成 10 秒会让稍大的聚合直接报错而报错信息看起来像连接断了实际是读超时。Java 侧的 JDBC URL 也有几个必带参数jdbc:mysql://adb-proxy.internal:3306/ads_demo ?useUnicodetrue characterEncodingutf8 useSSLfalse rewriteBatchedStatementstrue connectTimeout5000 socketTimeout120000rewriteBatchedStatementstrue这个参数在批量写入场景下影响很大它会把多条 INSERT 合并成一次网络往返不开启的话每条都要走一次 RTT导入几百万行时差距明显。socketTimeout对应上面的读超时逻辑批量导入时给足时间别用默认值。3.2 Druid 连接池四个必须动手改的参数指南 4.2.4 节专门给了 Druid 的连接池配置这个细节说明官方也承认「连接池默认参数不一定适配分析型负载」。我把实际调过的几个参数列出来参数建议值为什么这么设initialSize2 到 5建连有开销开太大启动瞬间打满连接数minIdle2保持少量长连接避免冷启动抖动maxActive不超过集群连接上限超限直接报 too many connectionsvalidationQuerySELECT 1空闲连接探活防止拿到已断开的连接testWhileIdletrue配合上一条取连接前先验一下maxWait3000拿不到连接快速失败别让线程无限等removeAbandonedtrue防连接泄漏业务代码忘关连接时兜底maxActive是最容易出事的一个。集群的连接数上限和规格相关具体数值要查你手上这份集群的实际配置不能拍脑袋写 100。我曾经见过一个服务把maxActive设成 200单实例压测没问题上了四个实例之后集群直接拒连报错信息还是那种看不出根因的通用错误最后靠SHOW PROCESSLIST才定位到。maxWait和connectTimeout是两层超时前者是「从池里拿连接等多久」后者是「建连等多久」。两个都设成默认值的话一个慢查询就可能把整条调用链拖死。我的习惯是maxWait给 3 秒让上游快速失败、走降级而不是耗在等待上。3.3 图形客户端DBeaver、Navicat 与 DBVisualizer 的兼容坑指南 4.4 节分别给了 DBVisualizer、DBeaver、Navicat 的连接步骤。这三款工具我都用过共性问题集中在驱动和元数据查询上。DBeaver 的坑在于它默认会去拉取最新版 MySQL 驱动而某些新版驱动对老服务端的握手协议支持有变化表现是「连接测试通过但一展开表结构就报错」。解决办法是在连接设置里指定驱动版本不要用自动下载的最新版。Navicat 的问题多半出在字符集新建连接时如果不手动指定 utf8mb4中文表名和字段注释会显示成问号。DBVisualizer 相对稳一些但它的默认超时较短跑一个稍大的查询就被自己掐断得在连接属性里把超时调大。一个通用建议排查连接问题时先用命令行排除账号和白名单再换图形工具。反过来的顺序会让你在驱动问题上耗很久最后发现其实是白名单没放通。4. SQL 手册怎么读数据类型、DDL/DML 边界与权限模型指南第 11 章是整份文档最厚的一章从数据类型一路写到 SELECT 语法和用户权限语句。这一章不适合从头读到尾正确用法是当成字典迁移和建表时逐项对照。真正需要提前吃透的是三块类型映射、建表语法里的分布与分区、以及 DML 那几个 MySQL 里没有的写法。4.1 数据类型映射从 MySQL 迁过来最先崩的几列分析型数据库的类型系统和 MySQL 高度相似但不是一一对应。迁移时最容易出问题的是这几类源端 MySQL 类型目标端常见写法需要注意的地方TINYINT(1)TINYINT 或布尔语义部分客户端会把 1 位整型映射成布尔值DECIMAL(p,s)保持相同精度和标度放大精度会明显增加存储和计算开销VARCHAR(255)按实际长度收窄分析场景宽表多字段长度要算总账TEXT / LONGTEXT尽量拆列或控制长度大字段会拖慢全表扫描DATETIMEDATETIME 或 TIMESTAMP注意时区设置跨时区同步容易错位JSON拆成普通列分析型场景里 JSON 函数支持有限别指望原地查询TINYINT(1)这条值得单独说。MySQL 里它常被当成布尔用JDBC 驱动在某些配置下会把值直接转成 true/false而目标端如果没有这个语义读出来就是 0 和 1业务代码里的判断全部反掉。迁移前把所有TINYINT(1)列扫一遍改成明确的TINYINT或者用整型存。DECIMAL的精度也别随手放大。很多人怕溢出把DECIMAL(10,2)统一改成DECIMAL(20,6)单列看没什么宽表乘上几亿行之后存储和聚合的代价都很实在。4.2 建表语法分布键和分区是性能的第一道闸门AnalyticDB MySQL 的建表语句在标准 MySQL 语法之外多了分布和分区的定义这两项直接决定数据怎么切、查询怎么并行。指南 11.2.2 节的 CREATE TABLE 给了完整语法这里给一个典型写法CREATE TABLE ads_order ( order_id BIGINT, user_id BIGINT, amount DECIMAL(12,2), dt DATE, channel VARCHAR(32) ) DISTRIBUTED BY HASH(order_id) -- 按订单号做哈希分布打散到各节点 PARTITION BY VALUE(DATE_FORMAT(dt, %Y%m%d)); -- 按天分区方便按日期裁剪分布键的选择有个基本判断优先选高基数、且经常出现在 JOIN 和 GROUP BY 里的列。选order_id是因为它基数高、分布均匀同时订单维度的查询最常用它关联。反面例子是拿channel这种只有几个取值的列做分布键数据会严重倾斜某些节点忙死、某些节点空转这个现象在监控上看就是节点间 CPU 使用率差距很大。分区键一般选时间列好处是查询带时间条件时能直接裁掉不相关的分区扫描量瞬间降一个数量级。PARTITION BY VALUE的具体支持范围以你手上版本的语法为准建表前翻一下 11.2.2 节的示例别照搬别处的写法。ALTER TABLE 在指南 11.2.3 节有单独说明需要提醒的是加列、改类型这类操作在数据量大的表上耗时不短而且可能影响正在跑的查询。生产环境变更表结构我一般挑低峰期并且提前在测试集群上跑一遍同样的语句看耗时。4.3 DML 的几个非 MySQL 写法与权限语句指南 11.3 节的 DML 里有几个在标准 MySQL 中不存在或者语义不同的写法REPLACE INTO和REPLACE SELECT FROM的语义是「存在则替换、不存在则插入」适合做小批量的幂等更新。但它底层是先删后插用在宽表上会产生不小的写入放大大批量场景要谨慎。INSERT OVERWRITE INTO SELECT是覆盖写通常会连分区一起覆盖做 T1 全量刷新时很好用但一定要把分区条件写全漏写就是整表覆盖这个失误的代价不用我多说。KILL PROCESS和SHOW PROCESSLIST在 11.3.9 和 11.3.10 节这两个是排障时的救命命令。有慢查询把资源占满时先用SHOW PROCESSLIST找到对应的连接 ID再KILL掉。注意别在生产高峰期随手 kill先确认那条 SQL 是不是核心任务。权限部分对应 11.5 到 11.10 节CREATE USER、GRANT、REVOKE、RENAME USER、DROP USER一整套都是标准语法。实际用下来权限设计的关键不是语法而是粒度按库授权最省事按表授权最安全按列授权基本用不上。指南 8.1 节的权限模型图值得看一眼它把高权限账号、普通账号、库、表之间的关系画清楚了比逐条读语法快。5. 避坑与排查五类高频故障的现象、原因与处置这一章是我自己踩过、也帮别人处理过的问题集合。共同点是报错信息都不太直观第一反应容易往错的方向查。5.1 连不上白名单、端口与连接数现象一客户端报连接超时但 ping 得通。原因基本是白名单没放通或者放通的是错误网段。ICMP 能通不代表 3306 端口通防火墙策略往往是分端口配的。 处置先在客户端用telnet 主机地址 3306试端口不通就去控制台核对白名单网段和实际出口 IP注意办公网出口 IP 可能变了。现象二报 too many connections。原因不是集群挂了是连接池上限和集群连接数上限不匹配多实例部署时尤其明显。 处置把每个实例的maxActive按「集群上限 ÷ 实例数 × 0.8」重算同时开removeAbandoned兜底。查当前连接可以执行SHOW PROCESSLIST看是不是有大量 Sleep 状态的空闲连接没释放。现象三能连上但一执行查询就断。常见原因是socketTimeout或read_timeout设得太小大查询被客户端主动掐断而报错信息看起来像服务端断开。 处置把超时按最长查询耗时往上放同时检查中间有没有负载均衡设备的空闲超时那一层也会掐连接。5.2 导不进、查得慢几类典型症状现象四批量导入跑到一半失败重试后数据重复。原因是同步任务没有做幂等失败重跑时前半段数据被写了两次。 处置把导入改成按分区覆盖写或者给目标表加唯一键配合REPLACE INTO。DataWorks 和 Kettle 两条链路都要注意这一点具体配置在指南第 10 章。现象五同样的 SQL昨天几秒今天几分钟。先别怀疑集群去查数据量是不是涨了、分区条件是不是漏了。分区裁剪失效是最常见的原因一条 SQL 少写一个dt条件扫描量可能就是几十倍。 处置把执行计划拉出来看扫描的分区数再对照 SQL 里的时间条件。指南 7.1 节的慢 SQL 部分给了查看入口配合SHOW PROCESSLIST一起用。6. 数据同步与慢 SQL两条链路和一套验证动作数据进得来这件事指南第 10 章给了两条路线DataWorks 和 Kettle。选择上我的判断很简单——如果源端是 RDS for MySQL、目标是做周期性的增量同步走 DataWorks它的数据源配置和任务调度是一体的出问题的地方少如果是本地文件、异构数据源、或者需要做一些转换逻辑Kettle 更灵活代价是调度和监控要自己搭。两条路线的共同坑都在字段映射上源端的TINYINT(1)、DATETIME到目标端怎么落一定要在任务配置里逐个字段确认别用默认映射一把梭。同步做完不要只看任务状态是「成功」。我一般会跑三个验证源端和目标端各跑一次COUNT(*)对总量按分区日期对一次当日增量再抽三五个业务主键逐字段比对。前两个能发现漏数第三个能发现字段错位后者最隐蔽往往要等报表出问题才暴露。慢 SQL 这块指南 7.1 节给的入口是起点真正定位还得落到执行计划上。我的习惯是先按耗时排序拉出 Top 20逐条看有没有全表扫描、有没有分布键参与 JOIN、有没有排序落盘。曾经有一条报表 SQL逻辑不复杂但 JOIN 的两张表分布键不一致每次都要做数据重分布跑一次要一分多钟。把其中一张表按关联列重建分布之后降到几秒。这类问题不看执行计划根本猜不到。-- 排查方向找出当天耗时最长的几条按耗时降序 SELECT sql_text, total_time, scan_rows FROM information_schema.slow_sql WHERE dt 2020-06-01 ORDER BY total_time DESC LIMIT 20;字段名以你手上版本的实际情况为准重点是养成「先看扫描行数、再看耗时」的顺序。扫描行数大而返回行数小通常是过滤条件没走到分区或者索引上扫描行数正常但耗时高多半卡在聚合和排序。从那以后我每次接手一个新集群都会先跑一遍这套三件套白名单连通性验证、连接池上限核对、Top 20 慢 SQL 摸底然后再动业务。这份 20200623 版指南在专有云的文档交付包里能拿到用之前先对一下产品的 build 号别拿新文档去套老集群语法差异会让你多走不少弯路。希望帮到你。本文还有配套的精品资源点击获取