GaussDB(DWS)数据仓库性能压测与调优实战：从0到1全记录
创建DWS集群
登录华为云控制台， “数据仓库服务GaussDB(DWS)”，点击“创建数据仓库集群”。
关键配置参数分享：
参数 推荐值 说明
计费模式 按需计费 演练完就释放，省钱
区域 华北-北京四 选离你最近的
产品类型 云数仓 标准版够用
节点规格 dwsx2.xlarge 最小规格即可
热数据存储 20G 测试够用
节点数量 3 分布式体验
网络配置：
虚拟私有云：新建一个VPC（如vpc-dws）
子网：选对应子网
安全组：自动创建
公网访问：现在购买，带宽选1Mbit/s
管理员密码：设置一个密码（大小写字母+数字+特殊字符），（一定要记住，后面连数据库要用）
连接DWS数据库
gsql-d gaussdb-h<公网IP>-U dbadmin-p8000-r-W<你的密码>成功连接后会看到postgres=>提示符
构造测试数据
创建测试表
-- 创建订单表（模拟业务场景）CREATETABLEorders(order_idBIGINTPRIMARYKEY,user_idBIGINT,product_idBIGINT,order_amountDECIMAL(10,2),order_statusVARCHAR(20),created_atTIMESTAMP,updated_atTIMESTAMP)DISTRIBUTEBYHASH(order_id);-- 创建用户表CREATETABLEusers(user_idBIGINTPRIMARYKEY,user_nameVARCHAR(100),user_phoneVARCHAR(20),user_statusVARCHAR(20),register_timeTIMESTAMP)DISTRIBUTEBYHASH(user_id);DISTRIBUTE BY HASH是指定分布键，数据会按这个字段的哈希值分散到不同节点。选错分布键会导致数据倾斜，影响性能。
插入测试数据
-- 插入100万用户INSERTINTOusersSELECTgenerate_series(1,1000000),'user_'||generate_series(1,1000000),'1'||lpad(generate_series(1,1000000)::text,10,'0'),CASEWHENrandom()>0.2THEN'active'ELSE'blocked'END,now()-(random()*interval'365 days');-- 插入1000万订单（分批插入，避免事务过大）INSERTINTOordersSELECTgenerate_series(1,10000000),(random()*999999+1)::BIGINT,(random()*9999+1)::BIGINT,(random()*1000+1)::DECIMAL(10,2),CASEWHENrandom()>0.9THEN'paid'WHENrandom()>0.7THEN'shipped'WHENrandom()>0.5THEN'pending_payment'ELSE'completed'END,now()-(random()*interval'180 days'),now()-(random()*interval'30 days');插入1000万条数据可能需要几分钟到十几分钟
收集统计信息
这是最容易忽略但最重要的一步——没有统计信息，优化器就不知道数据分布，生成的执行计划可能很烂。经验表明，10%左右的性能问题就是因为没收集统计信息。
ANALYZEorders;ANALYZEusers;生成WDR性能报告
WDR（Workload Diagnosis Report）是DWS自带的性能诊断工具，类似Oracle的AWR。它会定期采集数据库性能快照，然后生成两份快照之间的性能对比报告。
开启WDR快照
-- 开启WDR功能（默认开启）SETenable_wdr_snapshot=on;-- 手动创建快照（管理员权限）SELECTcreate_wdr_snapshot();查看已有快照
SELECT*FROMdbms_om.snapshotORDERBYsnapshot_idDESCLIMIT5;生成WDR报告
WDR报告包含的核心内容：
Top SQL by Elapsed Time：最耗时的SQL排名
等待事件分析：数据库在等什么资源（磁盘I/O、锁等）
慢SQL定位与分析
直接查TOP慢查询
SELECTquery_id,substring(query,1,100)ASquery_preview,calls,total_time/callsASavg_ms,rowsFROMdbe_perf.statement_historyWHEREstart_time>now()-interval'1 hour'ORDERBYtotal_timeDESCLIMIT10;使用EXPLAIN分析执行计划
-- 查看执行计划并实际执行（推荐，能看到真实耗时）EXPLAINANALYZESELECT*FROMordersWHEREuser_id=12345;实例对比
-- 建表并插入数据CREATETABLEstore_sales_row(ss_sold_date_skINT,ss_item_skINT,ss_quantityINT);INSERTINTOstore_sales_rowSELECTgenerate_series(1,5000000),generate_series(1,5000000),1;-- 不加索引：全表扫描，3.6秒EXPLAINANALYZESELECT*FROMstore_sales_rowWHEREss_sold_date_sk=2450944;-- 创建索引CREATEINDEXidx_sales_dateONstore_sales_row(ss_sold_date_sk);-- 加索引后：走Index Scan，13毫秒EXPLAINANALYZESELECT*FROMstore_sales_rowWHEREss_sold_date_sk=2450944;SQL调优实战
案例1：索引优化——WHERE条件没走索引
现象：查询按某字段过滤，但执行计划是Seq Scan（全表扫描）
CREATEINDEXidx_orders_user_idONorders(user_id);CREATEINDEXidx_orders_created_atONorders(created_at);-- 复合索引（多个条件同时过滤）CREATEINDEXidx_orders_user_status_createdONorders(user_id,order_status,created_atDESC);-- 再次分析ANALYZEorders;提醒：索引不是越多越好，每个索引都会占用存储空间，且写入时都要维护。一般建议在WHERE条件、JOIN关联列、ORDER BY排序列上建索引。
案例2：SQL改写——用EXISTS代替IN
-- 慢：子查询返回大量数据SELECT*FROMordersWHEREuser_idIN(SELECTuser_idFROMusersWHEREuser_status='blocked');-- 快：EXISTS可以提前终止，适合子表很大的情况SELECT*FROMorders oWHEREEXISTS(SELECT1FROMusers uWHEREu.user_id=o.user_idANDu.user_status='blocked');案例3：避免WHERE条件中使用函数
-- 慢：对created_at做DATE函数运算，无法走索引SELECT*FROMordersWHEREDATE(created_at)='2025-06-28';-- 快：用范围查询，可以走索引SELECT*FROMordersWHEREcreated_at>='2025-06-28 00:00:00'ANDcreated_at<'2025-06-29 00:00:00';**
GUC参数调优
内存相关参数
-- work_mem：排序和Hash操作的内存，默认512MB-- 复杂查询（5-10个关联）建议：50%内存/10-- 并发场景：串行值/并发数SETwork_mem='2GB';-- maintenance_work_mem：维护操作（VACUUM、CREATE INDEX）内存-- 建议不小于work_memSETmaintenance_work_mem='2GB';-- shared_buffers：共享内存，建议内存的40%以内-- 行存表设大，列存表设小SETshared_buffers='8GB';并发控制参数
-- max_active_statements：全局并发队列-- 分析类查询：设为CPU核数/DN个数，一般是4-8SETmax_active_statements=8;-- enable_dynamic_workload：开启动态负载管理（默认打开）SETenable_dynamic_workload=on;查询优化开关
-- 关闭排序归并（强制走HashJoin）SETenable_mergejoin=off;-- 关闭NestLoop（避免小表驱动大表的低效关联）SETenable_nestloop=off;-- 开启并行执行（SMP）SETquery_dop=4;-- 并行度，根据CPU核数设置问题 原因 解决方案
1 查询总是跑得很慢 没收集统计信息 执行ANALYZE 表名;
2 索引建了但不走 数据分布不均匀，优化器判断走全表更快 更新统计信息ANALYZE；或临时SET enable_seqscan=off;
3 数据倾斜导致某节点特别慢 分布键选得不合适 用SELECT table_skewness(‘表名’);检查，重新选分布键
4 WDR报告生成失败 enable_wdr_snapshot没开 SET enable_wdr_snapshot=on;
5 大表JOIN特别慢 关联列不是分布键，大量数据重分布 改写成先做INNER JOIN再LEFT JOIN的模式
6 索引推荐给的方案不合理 推荐合并了不该合并的索引