企业官网建设流程全解析

简介：面向数据库运维与容器化部署人员，这份zip资源包讲解了如何用Docker构建VASTBASE G100海量数据库镜像并完成容器化运行。内容围绕高性能数据库的快速交付场景，适合需要在大数据环境下简化安装、提升可移植性的团队参考。包内共有6个文件，涵盖Dockerfile、docker-entrypoint.sh启动脚本、数据库安装器tar.gz包、JDBC连接jar包、db_install.rsp静默安装响应文件及readme.txt说明文档，整体约496MB，各文件相互配合可完整还原镜像构建与实例启动链路。已有518人学习下载。借助其中的配置模板与启动流程说明，使用者能快速理解数据库容器化所需的核心步骤，包括系统参数设置、存储与内存分配、初始化逻辑以及常见问题处理，从而降低VASTBASE G100的部署门槛，提升大规模数据业务的交付效率。

1. 用Docker拉起VASTBASE G100：把MPP分析集群变成可以推倒重建的代码

用Docker构建海量数据库 VASTBASE G100，第一反应确实拧巴：一个奔着几百TB到PB级数据量去的MPP分析型数据库，怎么塞进容器里？但真在POC、版本选型、SQL性能回归这几类场景里滚过几轮后，你会发现多数时间不是花在调SQL上，而是花在反复重建环境、清理数据目录、验证不同分布策略上。把协调节点、数据节点、管理监控组件分别容器化，用docker-compose拉起一套1个协调节点加2个数据节点的最小集群，从空目录到能跑查询、能导亿行数据，压缩到十几分钟。这篇文章把完整部署方案、关键参数和常见坑一次讲清楚，适合数仓开发、数据平台工程师，以及正在做分析型数据库选型评估的团队。每一步都能直接抄，踩过的坑也会一并交代。

2. G100的组件分工与Docker化选型：为什么这个库适合容器跑

2.1 三类节点各自负责什么：协调、数据、管理组件

VASTBASE G100在架构上属于Shared Nothing的MPP分析型数据库，核心思路是“每个节点只处理自己那一份数据，节点之间不共享磁盘”。一次查询进来，协调节点负责SQL解析、生成执行计划，把可以并行执行的部分下推给各个数据节点，各节点在本地算完后，再由协调节点汇总结果。这个“计算下推”的模型，天然适合把节点当作独立单元来管理，容器恰好能提供这种单元化隔离。

集群里的角色大致分三类。GCluster节点也叫协调节点，对外提供服务、维护元数据，是SQL的入口；GNode节点就是数据节点，真正存数据和执行下推计算；另外还有gcmonit、corosync这类管理监控组件，负责进程守护和节点心跳检测。端口上，协调节点默认5258，数据节点默认5050，具体以你拿到的发行版为准。

理解这个分工后，容器化的映射关系就很清楚：一个协调节点容器，两个数据节点容器，管理组件按安装方式跟随节点部署。端口映射上只需要把协调节点的5258暴露给外部客户端，数据节点端口在集群内部互通即可。

2.2 三种值得容器化的场景：POC、回归测试、CI流水线

常见做法是拿容器跑三类工作。第一类是POC和选型评估。G100的部署在物理机或虚拟机上要准备多台机器、配SSH互信、跑安装脚本，一套环境从零到就绪经常要半天，而且环境一旦被测试污染，清理成本很高。容器化之后，一套compose文件就是一套环境，想对比不同分布键、不同副本策略的效果，直接复制目录再起一套，成本几乎为零。

第二类是版本升级和回归测试。数据卷独立挂载、镜像按版本打Tag，升级验证就是新Tag容器挂旧数据卷启动，发现问题立刻切回旧容器，后悔药是现成的。这一点在物理机上做很麻烦，目录、依赖、配置都要手工回滚。

第三类是CI流水线里的SQL审核和慢查询回归。把数据库集群当作流水线里的一个服务，像docker部署微服务项目一样编排进去，每次提交SQL变更就自动起一套临时集群跑一遍，跑完直接销毁。这个用法在物理机环境基本不可行，因为环境重建太慢。需要说明的是，这类场景对性能要求不高，容器化带来的部署速度优势远大于性能损耗。

2.3 边界在哪：哪些场合别硬上容器

容器不是万能的，尤其对数据库这种对资源和内核敏感的软件。先说结论：本地POC、测试、CI回归这类场景，容器化收益明显；生产环境的高性能分析型负载，要看具体情况。如果追求极致的I/O性能，数据文件应该挂裸设备或高性能存储卷，尽量避免写入容器可写层，因为可写层的I/O路径更长，还伴随镜像层膨胀问题。

另一个边界是NUMA绑定和CPU亲和。G100在数据节点上做大规模并行聚合时，CPU亲和和内存局部性对性能有可感知的影响，裸机或直通虚拟化在这方面仍然更有优势，容器里做NUMA绑定的手段有限而且配置麻烦。生产环境如果已经上了Kubernetes，建议用StatefulSet加init容器的方式管理，不要直接用compose管生产集群。本文后续方案定位在POC和测试集群，生产迁移时需要改动的点会单独标注。

3. 用docker-compose部署一套1+2的G100集群：从编排文件到集群初始化

3.1 先把目录和镜像准备好

部署前先做目录规划。常见的做法是项目根目录下分四个子目录：soft目录放官方安装包，data目录做各节点的数据卷挂载点，authkeys目录保存容器间SSH互信的公钥文件，logs目录留作容器日志落盘。数据卷单独挂载而不是放进镜像，原因有二：容器删除重建时数据不丢，以及磁盘I/O可以绕过容器可写层直接落到宿主机存储上。

gbase-cluster/ ├── soft/ # 官方安装包，tar.bz2格式 ├── data/ │ ├── coord/ # 协调节点数据目录 │ ├── data1/ # 数据节点1 │ └── data2/ # 数据节点2 ├── authkeys/ # 容器间SSH公钥交换目录 └── logs/ # 安装日志、运行日志

镜像层基于CentOS 7构建，这是GBase系列发行版最常见的适配系统。Dockerfile里做两件事：安装运行时依赖，把官方安装包提前COPY进镜像。依赖主要包括libaio和openssh相关组件，libaio是GBase底层异步I/O依赖的库，openssh-server和openssh-clients用于集群安装脚本跨节点分发文件。安装包文件名每个人拿到的可能不同，用ARG声明并在构建时传入可替换。

FROM centos:7 RUN yum install -y libaio ncurses-libs net-tools openssh-clients openssh-server && \ yum clean all ARG GBASE_PKG=GBase8a RUN mkdir -p /opt/soft /opt/gbase /data COPY soft/${GBASE_PKG}*.tar.bz2 /opt/soft/ ENV GBASE_HOME=/opt/gbase

构建镜像时的参数说明：GBASE_PKG对应你实际拿到的安装包主文件名，COPY指令用通配符匹配版本号部分，避免每次升级包都要改Dockerfile。构建命令是docker build --build-arg GBASE_PKG=GBase8a_NoLicense -t gbase-g100:latest .，不用privileged模式，镜像本身不需要特权。

3.2 编写docker-compose：网络固定IP、共享内存、数据卷

compose文件是整个部署的核心，服务的组织方式是1个协调节点加2个数据节点。有三件事必须在这层处理好。第一是网络，容器间通信要稳定，所以自定义bridge网络并给每个容器固定IP，避免重启后IP漂移导致集群配置失效。第二是共享内存，G100在集群聚合、排序等阶段依赖System V共享内存，Docker容器默认的64MB共享内存一定会出问题，显式设置shm_size为2g。第三是数据卷挂载，每个节点的数据目录分别挂载到宿主机data目录下。

version: '3.8' services: coord: image: gbase-g100:latest container_name: coord hostname: coord privileged: true networks: gbase_net: ipv4_address: ports: - "5258:5258" volumes: - ./data/coord:/data - ./authkeys:/opt/sshkeys - ./logs:/opt/logs shm_size: 2g environment: NODE_ROLE: coord DATA_NODES: "," CLUSTER_NAME: gbase_cluster depends_on: - data1 - data2 entrypoint: ["/opt/entrypoint.sh"] data1: image: gbase-g100:latest container_name: data1 hostname: data1 privileged: true networks: gbase_net: ipv4_address: volumes: - ./data/data1:/data - ./authkeys:/opt/sshkeys - ./logs:/opt/logs shm_size: 2g environment: NODE_ROLE: data entrypoint: ["/opt/entrypoint.sh"] data2: image: gbase-g100:latest container_name: data2 hostname: data2 privileged: true networks: gbase_net: ipv4_address: volumes: - ./data/data2:/data - ./authkeys:/opt/sshkeys - ./logs:/opt/logs shm_size: 2g environment: NODE_ROLE: data entrypoint: ["/opt/entrypoint.sh"] networks: gbase_net: driver: bridge ipam: config: - subnet: /24

参数说明：privileged模式是为了规避容器内调整内核参数和System V IPC权限受限的问题，POC阶段建议打开，上Kubernetes后要换成init容器方式并去掉特权。DATA_NODES环境变量填两个数据节点的固定IP，用逗号分隔，协调节点初始化集群时依据这个列表去找数据节点。shm_size是每个容器独立的共享内存上限，2g是一个经过验证的保守值，数据量更大的测试环境可以按每节点内存的1/4继续调高。entrypoint脚本统一入口，不同角色靠NODE_ROLE环境变量区分。

depends_on只解决启动顺序，不保证数据节点服务已就绪，所以脚本里还要自己做端口等待。

3.3 entrypoint脚本：SSH互信、安装、启动三条线串起来

容器里没有systemd，服务进程不会自动被托管，所以入口脚本要承担三件事：生成SSH密钥和互信关系、执行集群安装与初始化、启动本节点服务并防止容器退出。互信是GBase安装脚本分发文件的前提，协调节点需要免密SSH到两个数据节点，所以脚本设计成每个节点把自己的公钥写入共享卷，协调节点等待数据节点的公钥出现后统一合并authorized_keys。

#!/bin/bash # /opt/entrypoint.sh set -e ROLE=${NODE_ROLE} DATA_NODES=${DATA_NODES} AUTH_DIR=/opt/sshkeys GBASE_HOME=/opt/gbase # 1. 启动sshd，集群安装需要跨节点分发文件 mkdir -p /var/run/sshd /root/.ssh if [ ! -f /etc/ssh/ssh_host_rsa_key ]; then ssh-keygen -q -t rsa -f /etc/ssh/ssh_host_rsa_key -N '' fi if [ ! -f /root/.ssh/id_rsa ]; then ssh-keygen -q -t rsa -f /root/.ssh/id_rsa -N '' fi /usr/sbin/sshd # 2. 把本节点公钥发布到共享卷 mkdir -p ${AUTH_DIR} cp /root/.ssh/id_rsa.pub ${AUTH_DIR}/${HOSTNAME}.pub # 3. data节点后台持续同步公钥到authorized_keys sync_pub() { for i in $(seq 1 30); do sleep 2 cat ${AUTH_DIR}/*.pub > /root/.ssh/authorized_keys 2>/dev/null || true chmod 600 /root/.ssh/authorized_keys || true done } sync_pub & # 4. 协调节点等待所有数据节点SSH就绪，并合并公钥 if [ "${ROLE}" = "coord" ]; then for node in $(echo ${DATA_NODES} | tr ',' ' '); do for i in $(seq 1 30); do (echo > /dev/tcp/${node}/22) 2>/dev/null && break sleep 2 done done sleep 3 cat ${AUTH_DIR}/*.pub > /root/.ssh/authorized_keys chmod 600 /root/.ssh/authorized_keys # 5. 首次运行才执行安装，幂等判断 if [ ! -f ${GBASE_HOME}/.installed ]; then cd /opt/soft tar xjf /opt/soft/GBase8a*.tar.bz2 -C /opt/soft # 生成节点清单文件，按实际包内模板填写 # 核心参数：协调节点IP、数据节点IP列表、root密码 python gcinstall.py --silent gcinstall_config.xml touch ${GBASE_HOME}/.installed fi fi # 6. 启动本节点服务，由gcmonit守护 if [ "${ROLE}" = "coord" ]; then ${GBASE_HOME}/gcluster/server/bin/gcmonit.sh start else ${GBASE_HOME}/gnode/server/bin/gcmonit.sh start fi # 7. 保持容器前台运行 tail -f /opt/logs/*.log 2>/dev/null || sleep infinity

逻辑说明分几步走。第2步把公钥写到共享卷，是所有节点公钥汇聚的起点。第3步的sync_pub后台函数很关键，因为协调节点最后才合并公钥，数据节点需要在一个时间段内反复刷新authorized_keys才能拿到coord的公钥。第4步协调节点用/dev/tcp探测数据节点的22端口，等待SSH真正可连，然后合并所有公钥，这一步完成后协调节点就能免密ssh到两个数据节点。

安装阶段的幂等判断用标记文件实现，.installed存在就跳过安装直接启动服务。这样容器重启、compose再次up都不会重复执行安装脚本，避免把已经初始化的集群再初始化一遍。启动服务统一走gcmonit.sh，它会守护核心进程，服务异常退出时自动拉起。

提示：第5步的gcinstall命令参数以你拿到的官方安装手册为准，不同发行版的配置模板不一样，但核心动作固定为“填节点清单、执行安装、设置集群参数”。

3.4 执行一次完整部署：命令与预期输出

部署前先按3.1的目录结构建好文件夹，把官方安装包拷进soft目录，然后执行构建和启动。这里用到的都是标准docker安装和docker compose命令，Linux服务器上记得先确认docker daemon已启动。

# 构建镜像 docker build --build-arg GBASE_PKG=GBase8a_NoLicense -t gbase-g100:latest . # 启动集群 docker compose up -d # 查看容器状态 docker compose ps # 查看coord容器里的安装日志 docker logs -f coord

首次启动建议一直盯到coord容器日志里出现gcmonit启动成功的字样。安装过程会通过SSH往两个数据节点分发文件，耗时取决于安装包大小和本机磁盘速度，一般几分钟内完成。等日志稳定后，进入coord容器验证集群状态。

# 进入coord容器 docker exec -it coord bash # 加载GBase环境变量 export PATH=${GBASE_HOME}/gcluster/server/bin:${PATH} # 查看集群节点状态 gcadmin showcluster

showcluster的输出里，两个数据节点和协调节点的状态都应该是OPEN，任何一个节点状态不是ONLINE都说明初始化没完成。接着用gccli客户端登录数据库验证SQL层面可用，初始账号通常是root，密码来自你在安装配置里设置的值。

gccli -uroot -p'你的密码' -e "select version();"

到这里一套最小集群就算跑通了。接下来要解决的是参数调优和可能踩到的坑，这两部分决定了这套环境能不能从“能启动”变成“能扛住海量数据查询”。

4. G100容器化的关键参数：内核、分布策略与资源限额怎么设

4.1 内核与共享内存参数：容器最容易被卡住的两个点

G100这类使用共享内存做排序和聚合的数据库，对内核参数比一般应用敏感得多。容器场景下最典型的是System V共享内存限制：Docker默认给每个容器64MB的/dev/shm，gclusterd和gnode在启动时申请共享内存段，一旦超过就报shmget失败。这属于经典翻车点，不是数据库本身的问题，是容器的默认隔离参数太保守。compose里设置shm_size: 2g就能解决，但要知道这个值和宿主机参数kernel.shmmax、kernel.shmall是协同关系：容器共享内存上限不能超过宿主机允许的单段共享内存大小，否则申请依然失败。

另一个直接影响性能的内核参数是透明大页THP。数据库这类随机I/O密集的应用，THP会导致内存分配抖动，官方文档普遍建议关闭。容器内关THP不持久，而且权限受限，常见做法是宿主机上直接设置一次，然后启动容器时继承。

在Linux宿主机上，设置这些参数的命令是sysctl -w kernel.shmmax=...并写入/etc/sysctl.conf，THP用echo never > /sys/kernel/mm/transparent_hugepage/enabled。Windows或macOS上跑Docker Desktop就没有改内核参数的权限，只能靠调大shm_size来兜底，这也是前面说Docker Desktop只适合小型POC的原因。

4.2 分布键与副本参数：表和distribution怎么建才均衡

G100的“海量”能力很大程度靠表分布策略支撑。建表时指定DISTRIBUTED BY，数据按分布键的哈希值散列到各个数据节点，查询时协调节点才能把计算下推给所有节点并行执行。分布键选错了，数据全挤在一个节点上，MPP就退化成单机。另一个选择是复制表，适合维度表这类小表，每个节点存全量副本，关联查询时不需要跨节点传输数据。

-- 事实表：按哈希分布，order_id作为分布键 CREATE TABLE dwd_order_detail ( order_id BIGINT, user_id BIGINT, product_id BIGINT, amount DECIMAL(18,2), order_date DATE ) DISTRIBUTED BY ('order_id') HASH; -- 维度表：复制表，每个节点保存全量 CREATE TABLE dim_product ( product_id BIGINT, product_name VARCHAR(128), category VARCHAR(64) ) REPLICATED;

分布键的选择有几个经验值：优先选查询过滤条件里的等值字段，选join的关联字段，避免选枚举值极少的字段比如状态码，否则哈希分布会倾斜。distribution初始化时还有一个容易被忽略的参数是副本数。GBase默认要求副本数为2，也就是同一份数据在集群里存两份，一旦某个节点故障不影响查询。但最小验证集群只有2个数据节点时，默认副本数会直接导致初始化失败。

创建distribution时的副本参数按节点数量调整，常见做法是在gcadmin distribution命令里设置replica为1，让每个数据节点只保留一份数据。POC环境这么做是合理的，生产环境至少3个数据节点起步，保持默认的replica 2才有意义。这个参数也可以在集群初始化后再调整，但涉及数据重分布，耗时和风险都不小，最好建集群时就想清楚。

4.3 CPU、内存、磁盘的资源限额：POC和生产的两种配法

容器化部署G100时，资源限额不是拍脑袋定的。POC阶段追求的是“够用且能复现”，生产阶段追求的是“性能可预期”。协调节点对CPU要求不高，SQL解析和结果汇聚是它的主要负载；数据节点才是吃资源的地方，排序、聚合、哈希join都发生在数据节点上，CPU和内存都往这里倾斜。

compose文件里资源限额用mem_limit和cpus字段，POC环境建议直接给足，别把数据库跑在频繁swap的边缘。磁盘方面，G100的数据节点对随机读写敏感，容器数据卷尽量落在SSD上，避免多个节点共享同一块机械盘，否则并行加载时I/O会成为瓶颈。

还有一个隐藏较深的参数是文件句柄限制。数据节点并发高时，每个GNode进程会打开大量文件描述符，容器默认的ulimit nfile比较保守。compose里通过ulimits字段调高：

ulimits: nofile: soft: 65536 hard: 65536

设置这个参数的同时，宿主机fs.file-max也要同步检查，否则容器里放开到65536，宿主机层面仍然截断。检查命令是sysctl fs.file-max，一般服务器默认值足够支撑测试集群，但批量加载海量数据时值得确认。

5. 部署中的常见坑与排查：从共享内存不足到容器重启丢集群

5.1 Docker Desktop启动失败：virtualization support not detected

现象是docker desktop安装完成后启动直接报错，提示信息里出现virtualization support not detected，docker daemon完全起不来。这个坑通常在笔记本上做本地POC时碰到，和VASTBASE本身无关，但会卡住整个部署流程。

原因很直接：Docker Desktop依赖宿主机的虚拟化支持，BIOS里的Intel VT-x或AMD-V没有开启，或者Windows的Hyper-V组件没就绪。排查时先打开任务管理器查看虚拟化是否显示“已启用”，没启用就进BIOS打开，然后重启。如果虚拟化已经启用仍然报错，检查Windows功能里Hyper-V和虚拟机平台是否同时勾选，有时旧版本Hyper-V和新版Docker Desktop冲突。

解决后建议先跑一个hello-world容器确认docker正常，再回到项目目录执行docker compose up。这类环境层面的问题要先于项目排错，别一上来就查GBase的日志。

5.2 gclusterd反复重启失败：共享内存不够

现象是容器能起来，但coord容器里gclusterd进程启动后马上退出，日志里出现shmget或System V IPC相关的错误编号，gcmonit反复拉起又反复失败。

原因是容器默认共享内存只有64MB，G100的协调节点在启动时申请全局共享内存段，超过了这个限制。这个坑在物理机上几乎不存在，是容器化特有的。解决分两步：compose文件里设置shm_size: 2g，同时确认宿主机kernel.shmmax足够大。如果宿主机shmmax只有几百MB，容器里设再大也白搭。用sysctl kernel.shmmax查看，不合适就临时调大测试，确认有效再写入sysctl.conf持久化。

5.3 初始化时报数据目录不可写：容器内外UID错位

现象是gcinstall执行到某个阶段失败，报/opt/gbase或/data目录下创建文件权限不足，但进容器看root用户明明是万能的，目录属主也没问题，很迷惑。

原因在于容器内进程以gbase用户运行，这个用户在构建镜像时被创建，UID通常是500或1000。宿主机挂载进来的空数据卷继承宿主机的属主和权限，容器内gbase用户没有写权限。这是典型的容器内外用户权限错位。解决方式是对挂载的宿主机目录递归授权给对应UID。假设容器内gbase用户的UID是500，在宿主机上执行：

chown -R 500:500 ./data chown -R 500:500 ./logs

不想记UID就进容器执行id gbase查一下。这个操作要在启动容器前完成，否则初始化跑到一半再补权限，又得清掉重来。数据卷权限问题会在每次重建数据目录时出现，建议写进部署文档里作为固定前置步骤。

5.4 宿主机重启后集群全部OFFLINE：entrypoint没做幂等启动

现象是宿主机重启后，docker compose up -d能把容器拉起来，但进coord容器执行gcadmin showcluster，所有节点状态都是OFFLINE，数据库完全不可用。初次部署的人会怀疑集群数据损坏了，其实数据都还在。

原因是镜像里服务进程没有被持久托管。容器启动时entrypoint如果只负责初始化而不负责启动服务，重启后容器虽然是up状态，但里面的gclusterd、gnode进程根本没有运行。解决方式是entrypoint脚本对所有角色都要做“检测进程态、缺了就启动”的逻辑。上面3.3版本里的gcmonit.sh start正好覆盖了这一步，因为gcmonit会拉起并守护核心进程。如果你修改了entrypoint或者沿用了简化版脚本，记得补上这段。

还有一个连带检查点：重启后容器IP是否变化。compose里固定了IP一般不会变，但如果改了网络配置或删除重建了网络，固定IP失效，集群节点间通信就会中断，现象同样是OFFLINE。

5.5 init distribution失败：副本数大于数据节点数

现象是安装过程顺利，但执行gcadmin distribution初始化时失败，提示副本数不满足要求。

原因是distribution默认配置的副本数是2，最少需要3个数据节点才能满足。1+2架构下只有2个数据节点，校验直接不通过。解决方式是建distribution时指定副本数为1，把初始化命令里的replica参数改成1再执行。这也是前面4.2节强调副本参数的原因。如果业务需要双副本冗余，方案很简单：再加一个数据节点容器，扩到1+3架构，保持默认副本数即可。这里要注意扩容不是简单复制一个服务定义，还要同步修改协调节点的DATA_NODES环境变量和安装配置里的节点清单，然后重新执行安装脚本完成节点添加。

6. 用1亿行数据验证部署质量：加载、分布均衡与查询计划

6.1 生成一份1亿行的订单明细CSV

海量数据库部署完，先别急着上业务查询，用一份可控的测试数据验证分布和查询计划。生成数据用简单的Python脚本，按订单明细的形态造1亿行订单号、用户ID、商品ID和金额。注意生成脚本和数据库不在同一个容器里，输出文件直接写到宿主机data目录，再通过数据卷挂载进协调节点容器。

import random with open("/data/order_detail.csv", "w") as f: for i in range(100_000_000): f.write(f"{i},{random.randint(1, 1000000)},{random.randint(1, 10000)},{random.randint(1, 10000)/100}\n")

1亿行CSV大约1.5GB，生成耗时几分钟，建议先跑小规模验证脚本逻辑，再放开到全量。这份CSV对应前面建的dwd_order_detail表，字段顺序和建表语句保持一致。

6.2 load data infile加载和分布均衡验证

GBase兼容MySQL的LOAD DATA语法，从CSV批量灌数比逐条INSERT快几个数量级。进入coord容器执行加载：

LOAD DATA INFILE '/data/order_detail.csv' INTO TABLE dwd_order_detail FIELDS TERMINATED BY ',';

加载完成后用gcadmin showdistribution查看两个数据节点的数据条数应该基本接近，这是分布键选得好的直接证据。如果某个节点数据量明显偏高，说明分布键选择有问题，需要重建表换分布键，否则后续所有查询都会倾斜。

6.3 用explain确认计算下推是否生效

分布均衡只是第一步，真正体现MPP价值的是查询计划。执行：

EXPLAIN SELECT COUNT(*), SUM(amount) FROM dwd_order_detail WHERE user_id < 100;

重点看执行计划里是否出现两个数据节点各自扫描本地数据然后汇聚的描述。如果计划里只有一个节点扫描全量数据，说明分布没有生效，查询退化成单机扫描。确认下推没问题后，可以实际跑几条聚合查询，用time观察耗时。这套验证流程每次改节点配置、调分布键、升级镜像后都值得重跑一遍。

这套compose方案我现在还在用，每次改compose文件后都会强制自己走一遍“销毁重建”流程：docker compose down再把data目录清空，从零初始化一次。凡是没写幂等entrypoint的镜像，后面一定会坑到自己；凡是没验证分布均衡的集群，上线后SQL性能一定会给你惊喜。多花十分钟做验证，比上线后熬夜排错划算得多。希望帮到你。

本文还有配套的精品资源，点击获取