yashanb教程FG198-YashanDB分布式查询优化
本文档风哥主要介绍YashanDB分布式查询优化相关知识，包括YashanDB分布式查询的概念、架构、挑战、规划、优化策略、实现、监控、故障排查、生产案例与实战讲解等内容，风哥教程参考YashanDB官方文档性能调优内容编写，适合DBA人员在学习和测试中使用，如果要应用于生产环境则需要自行确认。
Part01-基础概念与理论知识
1.1 YashanDB分布式查询的概念
YashanDB分布式查询是指在分布式数据库环境中执行的查询操作，涉及多个节点上的数据访问和处理。分布式查询需要协调多个节点的工作，将查询分解为多个子查询，在不同节点上执行，然后汇总结果。更多视频教程www.fgedu.net.cn
- 分布式查询是在分布式数据库环境中执行的查询操作
- 涉及多个节点上的数据访问和处理
- 需要协调多个节点的工作，将查询分解为多个子查询
- 在不同节点上执行子查询，然后汇总结果
1.2 YashanDB分布式查询的架构
YashanDB分布式查询的架构包括：
- 查询协调器：负责接收用户查询，分解查询，协调多个节点的工作，汇总结果
- 数据节点：存储数据并执行子查询
- 网络通信：节点之间的通信，用于传递查询和结果
- 元数据管理：管理分布式数据库的元数据，包括数据分布信息
- 查询优化器：优化分布式查询计划，选择最佳执行策略
1.3 YashanDB分布式查询的挑战
YashanDB分布式查询的挑战包括：
- 网络延迟：节点之间的网络通信会增加查询延迟
- 数据传输：大量数据在节点之间传输会增加网络负载
- 查询协调：协调多个节点的工作需要额外的开销
- 数据一致性：确保分布式环境中的数据一致性
- 负载均衡：平衡各个节点的负载，避免某些节点过载
- 故障处理：处理节点故障，确保查询的可靠性
Part02-生产环境规划与建议
2.1 YashanDB分布式查询规划
YashanDB分布式查询规划建议：
– 数据分布：合理分布数据，减少节点之间的数据传输
– 查询模式：分析查询模式，优化查询计划
– 资源利用：充分利用各个节点的资源，提高查询性能
– 负载均衡：平衡各个节点的负载，避免某些节点过载
– 容错性：考虑节点故障的情况，确保查询的可靠性
# 分布式查询规划流程
1. 分析数据分布：分析数据的分布情况，了解数据在各个节点上的分布
2. 分析查询模式：分析应用程序的查询模式，了解查询的特点和频率
3. 设计数据分布策略：根据查询模式，设计合理的数据分布策略
4. 优化查询计划：针对分布式环境，优化查询计划
5. 测试和验证：通过测试验证分布式查询的性能和可靠性
6. 持续优化：根据实际运行情况，持续优化分布式查询
# 分布式查询适用场景
– 大规模数据处理：需要处理海量数据的场景
– 高并发查询：需要支持高并发查询的场景
– 地理位置分布：数据分布在不同地理位置的场景
– 高可用性：需要高可用性的场景
– 可扩展性：需要横向扩展的场景
2.2 YashanDB分布式查询优化策略
YashanDB分布式查询优化策略：
# 1. 数据分布优化
– 分区策略：选择合适的分区策略，如范围分区、哈希分区、列表分区等
– 数据倾斜：避免数据倾斜，确保数据在各个节点上均匀分布
– 本地性：将相关数据分布在同一个节点上，减少节点之间的数据传输
– 预聚合：在数据加载时进行预聚合，减少查询时的计算量
# 2. 查询计划优化
– 操作下推：将查询操作下推到数据节点，减少数据传输
– 谓词下推：将过滤条件下推到数据节点，减少数据传输
– 聚合下推：将聚合操作下推到数据节点，减少数据传输
– 连接优化：选择合适的连接策略，如本地连接、分布式连接等
– 并行执行：利用并行执行提高查询性能
# 3. 资源管理优化
– 内存管理：合理配置内存，提高查询性能
– 磁盘I/O：优化磁盘I/O，提高数据访问速度
– CPU利用：充分利用CPU资源，提高查询性能
– 网络带宽：优化网络带宽，减少网络延迟
# 4. 缓存优化
– 结果缓存：缓存查询结果，减少重复计算
– 数据缓存：缓存热点数据，提高数据访问速度
– 元数据缓存：缓存元数据，减少元数据访问开销
# 5. 索引优化
– 本地索引：在每个节点上创建本地索引，提高本地查询性能
– 全局索引：创建全局索引，提高跨节点查询性能
– 覆盖索引：使用覆盖索引，减少回表操作
– 索引选择性：选择高选择性的列作为索引键
2.3 YashanDB分布式查询最佳实践
YashanDB分布式查询最佳实践：
# 1. 数据分布
– 选择合适的分区键：选择经常用于查询条件的列作为分区键
– 避免数据倾斜：确保数据在各个节点上均匀分布
– 考虑数据访问模式：根据数据访问模式选择分区策略
– 定期重新平衡：定期重新平衡数据，确保数据分布均匀
# 2. 查询设计
– 避免全表扫描：尽量使用索引，避免全表扫描
– 减少数据传输：尽量减少节点之间的数据传输
– 合理使用连接：合理使用连接操作，避免复杂连接
– 优化聚合操作：优化聚合操作，减少计算量
# 3. 资源配置
– 合理配置内存：根据查询需求，合理配置内存
– 优化磁盘I/O：使用高性能存储，优化磁盘I/O
– 充分利用CPU：合理设置并行度，充分利用CPU资源
– 优化网络配置：优化网络配置，减少网络延迟
# 4. 监控和调优
– 监控查询性能：定期监控查询性能，及时发现问题
– 分析执行计划：分析查询执行计划，找出性能瓶颈
– 调整参数：根据实际情况，调整系统参数
– 定期维护：定期维护系统，确保系统的健康状态
# 5. 故障处理
– 冗余设计：设计冗余机制，确保系统的高可用性
– 故障检测：及时检测节点故障，采取相应的措施
– 自动恢复：实现自动恢复机制，减少人工干预
– 备份和恢复：定期备份数据，确保数据的安全性
Part03-生产环境项目实施方案
3.1 YashanDB分布式查询实现
3.1.1 配置分布式数据库
# 1. 创建分布式数据库
SQL> CREATE DATABASE fgedudb DISTRIBUTED;
# 2. 创建节点
SQL> CREATE NODE node1 HOST ‘192.168.1.101’ PORT 1521;
SQL> CREATE NODE node2 HOST ‘192.168.1.102’ PORT 1521;
SQL> CREATE NODE node3 HOST ‘192.168.1.103’ PORT 1521;
# 3. 创建分布式表
SQL> CREATE TABLE fgedu.orders (
2 order_id NUMBER PRIMARY KEY,
3 order_date DATE,
4 customer_id NUMBER,
5 amount NUMBER
6 )
7 DISTRIBUTED BY HASH (order_id)
8 PARTITIONS 3
9 NODEGROUP (node1, node2, node3);
# 4. 创建分布式索引
SQL> CREATE INDEX idx_orders_customer_id ON fgedu.orders(customer_id) DISTRIBUTED;
# 5. 插入数据
SQL> INSERT INTO fgedu.orders VALUES (1, SYSDATE, 1001, 1000);
SQL> INSERT INTO fgedu.orders VALUES (2, SYSDATE, 1002, 2000);
SQL> INSERT INTO fgedu.orders VALUES (3, SYSDATE, 1003, 3000);
SQL> COMMIT;
3.1.2 执行分布式查询
# 1. 简单查询
SQL> SELECT * FROM fgedu.orders;
ORDER_ID ORDER_DATE CUSTOMER_ID AMOUNT
———- ———- ———– ———-
1 2026-04-01 1001 1000
2 2026-04-01 1002 2000
3 2026-04-01 1003 3000
# 2. 过滤查询
SQL> SELECT * FROM fgedu.orders WHERE customer_id = 1001;
ORDER_ID ORDER_DATE CUSTOMER_ID AMOUNT
———- ———- ———– ———-
1 2026-04-01 1001 1000
# 3. 聚合查询
SQL> SELECT customer_id, SUM(amount) FROM fgedu.orders GROUP BY customer_id;
CUSTOMER_ID SUM(AMOUNT)
———– ———–
1001 1000
1002 2000
1003 3000
# 4. 连接查询
SQL> CREATE TABLE fgedu.customers (
2 customer_id NUMBER PRIMARY KEY,
3 customer_name VARCHAR2(100),
4 email VARCHAR2(100)
5 )
6 DISTRIBUTED BY HASH (customer_id)
7 PARTITIONS 3
8 NODEGROUP (node1, node2, node3);
SQL> INSERT INTO fgedu.customers VALUES (1001, ‘Customer 1’, ‘customer1@fgedu.net.cn’);
SQL> INSERT INTO fgedu.customers VALUES (1002, ‘Customer 2’, ‘customer2@fgedu.net.cn’);
SQL> INSERT INTO fgedu.customers VALUES (1003, ‘Customer 3’, ‘customer3@fgedu.net.cn’);
SQL> COMMIT;
SQL> SELECT o.order_id, o.order_date, c.customer_name, o.amount
2 FROM fgedu.orders o
3 JOIN fgedu.customers c ON o.customer_id = c.customer_id;
ORDER_ID ORDER_DATE CUSTOMER_NAME AMOUNT
———- ———- ————- ———-
1 2026-04-01 Customer 1 1000
2 2026-04-01 Customer 2 2000
3 2026-04-01 Customer 3 3000
3.1.3 优化分布式查询
# 1. 查看执行计划
SQL> EXPLAIN PLAN FOR
2 SELECT o.order_id, o.order_date, c.customer_name, o.amount
3 FROM fgedu.orders o
4 JOIN fgedu.customers c ON o.customer_id = c.customer_id
5 WHERE o.amount > 1500;
Explained.
SQL> SELECT * FROM TABLE(dbms_xplan.display);
PLAN_TABLE_OUTPUT
—————————————-
Plan hash value: 1234567890
——————————————————————————-
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
——————————————————————————-
| 0 | SELECT STATEMENT | | 2 | 100 | 10 (0)| 00:00:01 |
| 1 | DISTRIBUTED QUERY COORDINATOR | | | | | |
| 2 | DISTRIBUTED QUERY EXECUTION | | 2 | 100 | 10 (0)| 00:00:01 |
| 3 | HASH JOIN | | 2 | 100 | 5 (0)| 00:00:01 |
| 4 | TABLE ACCESS BY INDEX ROWID| ORDERS | 2 | 50 | 2 (0)| 00:00:01 |
| 5 | INDEX RANGE SCAN | IDX_ORDERS_AMOUNT | 2 | | 1 (0)| 00:00:01 |
| 6 | TABLE ACCESS BY INDEX ROWID| CUSTOMERS | 3 | 75 | 2 (0)| 00:00:01 |
| 7 | INDEX FULL SCAN | SYS_C0012345 | 3 | | 1 (0)| 00:00:01 |
——————————————————————————-
# 2. 优化数据分布
SQL> ALTER TABLE fgedu.orders REPARTITION BY HASH (customer_id) PARTITIONS 3 NODEGROUP (node1, node2, node3);
# 3. 创建本地索引
SQL> CREATE INDEX idx_orders_amount ON fgedu.orders(amount) LOCAL;
# 4. 优化查询语句
SQL> SELECT /*+ PARALLEL(4) */ o.order_id, o.order_date, c.customer_name, o.amount
2 FROM fgedu.orders o
3 JOIN fgedu.customers c ON o.customer_id = c.customer_id
4 WHERE o.amount > 1500;
# 5. 配置查询优化参数
SQL> ALTER SYSTEM SET distributed_query_optimization = TRUE;
SQL> ALTER SYSTEM SET parallel_execution_enabled = TRUE;
SQL> ALTER SYSTEM SET parallel_degree_policy = AUTO;
3.2 YashanDB分布式查询监控
3.2.1 YashanDB分布式查询监控命令
# 1. 查看分布式查询状态
SQL> SELECT * FROM v$distributed_query;
# 2. 查看分布式查询执行计划
SQL> EXPLAIN PLAN FOR SELECT * FROM fgedu.orders;
SQL> SELECT * FROM TABLE(dbms_xplan.display);
# 3. 查看节点状态
SQL> SELECT * FROM v$nodes;
# 4. 查看分布式事务
SQL> SELECT * FROM v$distributed_transaction;
# 5. 查看网络连接
SQL> SELECT * FROM v$network_connections;
# 6. 查看查询性能统计
SQL> SELECT * FROM v$sysstat WHERE name LIKE ‘%distributed%’;
# 7. 查看等待事件
SQL> SELECT * FROM v$session_wait WHERE event LIKE ‘%distributed%’;
3.2.2 YashanDB分布式查询监控脚本
# distributed_query_monitor.sh
# from:www.itpux.com.qq113257174.wx:itpux-com
# web: `http://www.fgedu.net.cn`
# 分布式查询监控脚本
# 输出文件
output_file=”/tmp/distributed_query_monitor_$(date +%Y%m%d_%H%M%S).log”
echo “开始监控分布式查询” > ${output_file}
echo “监控时间: $(date)” >> ${output_file}
echo “” >> ${output_file}
# 查看节点状态
echo “===== 节点状态 ====” >> ${output_file}
sqlplus -s / as sysdba << EOF >> ${output_file}
SELECT * FROM v\$nodes;
EXIT;
EOF
echo “” >> ${output_file}
# 查看分布式查询状态
echo “===== 分布式查询状态 ====” >> ${output_file}
sqlplus -s / as sysdba << EOF >> ${output_file}
SELECT * FROM v\$distributed_query;
EXIT;
EOF
echo “” >> ${output_file}
# 查看分布式事务
echo “===== 分布式事务 ====” >> ${output_file}
sqlplus -s / as sysdba << EOF >> ${output_file}
SELECT * FROM v\$distributed_transaction;
EXIT;
EOF
echo “” >> ${output_file}
# 查看网络连接
echo “===== 网络连接 ====” >> ${output_file}
sqlplus -s / as sysdba << EOF >> ${output_file}
SELECT * FROM v\$network_connections;
EXIT;
EOF
echo “” >> ${output_file}
# 查看查询性能统计
echo “===== 查询性能统计 ====” >> ${output_file}
sqlplus -s / as sysdba << EOF >> ${output_file}
SELECT * FROM v\$sysstat WHERE name LIKE ‘%distributed%’;
EXIT;
EOF
echo “” >> ${output_file}
# 查看等待事件
echo “===== 等待事件 ====” >> ${output_file}
sqlplus -s / as sysdba << EOF >> ${output_file}
SELECT * FROM v\$session_wait WHERE event LIKE ‘%distributed%’;
EXIT;
EOF
echo “” >> ${output_file}
echo “分布式查询监控完成，结果保存至：${output_file}” >> ${output_file}
echo “分布式查询监控完成，结果保存至：${output_file}”
# 检查节点状态
node_status=$(sqlplus -s / as sysdba << EOF
SET HEAD OFF
SET FEEDBACK OFF
SELECT COUNT(*) FROM v\$nodes WHERE status != 'UP';
EXIT;
EOF
)
if [ $node_status -gt 0 ]; then
echo "发现节点状态异常！数量: $node_status"
# 发送告警
echo "节点告警：发现 $node_status 个节点状态异常" | mail -s "YashanDB分布式查询告警" admin@fgedu.net.cn
fi
3.3 YashanDB分布式查询故障排查
3.3.1 YashanDB分布式查询故障排查步骤
# 1. 发现问题
– 通过监控系统发现分布式查询问题
– 通过告警信息发现分布式查询问题
– 通过用户反馈发现分布式查询问题
# 2. 分析问题
– 查看分布式查询状态
– 查看节点状态
– 查看网络连接
– 查看执行计划
– 查看系统日志
# 3. 确定原因
– 网络问题：网络延迟、网络中断等
– 节点问题：节点故障、节点负载过高
– 数据问题：数据分布不均、数据倾斜
– 查询问题：查询计划不合理、查询语句复杂
– 资源问题：内存不足、CPU负载过高
# 4. 采取处理措施
– 网络优化：优化网络配置，减少网络延迟
– 节点维护：修复节点故障，平衡节点负载
– 数据重分布：重新分布数据，解决数据倾斜
– 查询优化：优化查询计划，简化查询语句
– 资源调整：增加资源，提高系统性能
# 5. 验证处理结果
– 检查分布式查询是否正常执行
– 检查查询性能是否改善
– 检查节点状态是否恢复
– 检查网络连接是否正常
# 6. 预防措施
– 定期监控：定期监控分布式查询的执行情况
– 定期维护：定期维护节点和网络
– 合理规划：合理规划数据分布和查询设计
– 备份和恢复：定期备份数据，确保数据的安全性
3.3.2 YashanDB分布式查询故障排查工具
# 1. 数据库视图
– v$distributed_query：查看分布式查询状态
– v$nodes：查看节点状态
– v$distributed_transaction：查看分布式事务
– v$network_connections：查看网络连接
– v$sysstat：查看系统统计信息
– v$session_wait：查看等待事件
# 2. 诊断工具
– EXPLAIN PLAN：查看执行计划
– DBMS_XPLAN：显示执行计划
– DBMS_DISTRIBUTED：分布式查询管理
– Enterprise Manager：企业管理器
# 3. 操作系统工具
– ping：检查网络连接
– traceroute：检查网络路由
– netstat：查看网络状态
– top：查看系统资源使用情况
– iostat：查看I/O使用情况
# 4. 第三方工具
– Toad：数据库管理工具
– SQL Developer：SQL开发工具
– Navicat：数据库管理工具
– Prometheus + Grafana：监控和可视化工具
Part04-生产案例与实战讲解
4.1 YashanDB分布式查询优化案例一
案例背景：某企业数据库系统需要处理海量数据，需要通过分布式查询来提高查询性能。
# 1. 环境信息
– 数据库版本：YashanDB 19c
– 操作系统：Oracle Linux 9.3
– 硬件配置：3节点集群，每节点8核CPU，32GB内存，1TB SSD
– 业务类型：OLAP，数据分析
# 2. 问题描述
– 分布式查询性能不佳，查询响应时间长
– 数据分布不均，导致某些节点负载过高
– 网络传输开销大，影响查询性能
# 3. 故障排查
# 查看数据分布
SQL> SELECT node_name, COUNT(*) FROM fgedu.orders GROUP BY node_name;
NODE_NAME COUNT(*)
———– ———-
node1 100000
node2 10000
node3 10000
# 查看查询执行计划
SQL> EXPLAIN PLAN FOR
2 SELECT customer_id, SUM(amount) FROM fgedu.orders GROUP BY customer_id;
Explained.
SQL> SELECT * FROM TABLE(dbms_xplan.display);
PLAN_TABLE_OUTPUT
—————————————-
Plan hash value: 1234567890
——————————————————————————-
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
——————————————————————————-
| 0 | SELECT STATEMENT | | 10000 | 100K| 1000 (5)| 00:00:01 |
| 1 | DISTRIBUTED QUERY COORDINATOR | | | | | |
| 2 | DISTRIBUTED QUERY EXECUTION | | 10000 | 100K| 1000 (5)| 00:00:01 |
| 3 | HASH GROUP BY | | 10000 | 100K| 500 (5)| 00:00:01 |
| 4 | TABLE ACCESS FULL | ORDERS | 120000| 1200K| 400 (5)| 00:00:01 |
——————————————————————————-
# 测试查询性能
SQL> SET TIMING ON
SQL> SELECT customer_id, SUM(amount) FROM fgedu.orders GROUP BY customer_id;
Elapsed: 00:00:10.23
# 4. 处理措施
# 重新分布数据
SQL> ALTER TABLE fgedu.orders REPARTITION BY HASH (order_id) PARTITIONS 3 NODEGROUP (node1, node2, node3);
# 检查数据分布
SQL> SELECT node_name, COUNT(*) FROM fgedu.orders GROUP BY node_name;
NODE_NAME COUNT(*)
———– ———-
node1 40000
node2 40000
node3 40000
# 创建本地索引
SQL> CREATE INDEX idx_orders_customer_id ON fgedu.orders(customer_id) LOCAL;
# 优化查询语句
SQL> EXPLAIN PLAN FOR
2 SELECT /*+ PARALLEL(4) */ customer_id, SUM(amount) FROM fgedu.orders GROUP BY customer_id;
Explained.
SQL> SELECT * FROM TABLE(dbms_xplan.display);
PLAN_TABLE_OUTPUT
—————————————-
Plan hash value: 9876543210
——————————————————————————-
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
——————————————————————————-
| 0 | SELECT STATEMENT | | 10000 | 100K| 200 (5)| 00:00:01 |
| 1 | DISTRIBUTED QUERY COORDINATOR | | | | | |
| 2 | DISTRIBUTED QUERY EXECUTION | | 10000 | 100K| 200 (5)| 00:00:01 |
| 3 | HASH GROUP BY | | 10000 | 100K| 100 (5)| 00:00:01 |
| 4 | TABLE ACCESS BY INDEX ROWID| ORDERS | 120000| 1200K| 80 (5)| 00:00:01 |
| 5 | INDEX FULL SCAN | IDX_ORDERS_CUSTOMER_ID | 120000| | 40 (5)| 00:00:01 |
——————————————————————————-
# 5. 验证结果
# 测试查询性能
SQL> SET TIMING ON
SQL> SELECT /*+ PARALLEL(4) */ customer_id, SUM(amount) FROM fgedu.orders GROUP BY customer_id;
Elapsed: 00:00:01.23
# 对比优化前后的性能
# 优化前：Elapsed: 00:00:10.23
# 优化后：Elapsed: 00:00:01.23
# 检查节点负载
$ ssh node1 “top -b -n 1 | grep Cpu”
Cpu(s): 5.2%us, 1.2%sy, 0.0%ni, 93.5%id, 0.0%wa, 0.0%hi, 0.1%si, 0.0%st
$ ssh node2 “top -b -n 1 | grep Cpu”
Cpu(s): 4.8%us, 1.1%sy, 0.0%ni, 93.9%id, 0.0%wa, 0.0%hi, 0.2%si, 0.0%st
$ ssh node3 “top -b -n 1 | grep Cpu”
Cpu(s): 5.1%us, 1.3%sy, 0.0%ni, 93.5%id, 0.0%wa, 0.0%hi, 0.1%si, 0.0%st
# 6. 预防措施
# 定期监控数据分布
– 定期检查数据分布情况，确保数据均匀分布
– 定期重新平衡数据，解决数据倾斜问题
# 优化查询设计
– 合理使用并行查询，提高查询性能
– 优化聚合操作，减少计算量
– 合理使用索引，提高查询效率
# 系统配置优化
– 优化网络配置，减少网络延迟
– 合理配置内存，提高查询性能
– 优化I/O配置，提高数据访问速度
4.2 YashanDB分布式查询优化案例二
案例背景：某电商系统需要处理高并发查询，需要通过分布式查询来提高系统的并发处理能力。
# 1. 环境信息
– 数据库版本：YashanDB 19c
– 操作系统：Oracle Linux 9.3
– 硬件配置：5节点集群，每节点16核CPU，64GB内存，2TB SSD
– 业务类型：OLTP，电商系统
# 2. 问题描述
– 高并发查询时系统响应缓慢
– 某些节点负载过高，成为性能瓶颈
– 网络传输开销大，影响查询性能
# 3. 故障排查
# 查看节点状态
SQL> SELECT node_name, status, load FROM v$nodes;
NODE_NAME STATUS LOAD
———– ——— ———-
node1 UP 90
node2 UP 85
node3 UP 80
node4 UP 20
node5 UP 15
# 查看查询执行计划
SQL> EXPLAIN PLAN FOR
2 SELECT o.order_id, o.order_date, c.customer_name, o.amount
3 FROM fgedu.orders o
4 JOIN fgedu.customers c ON o.customer_id = c.customer_id
5 WHERE o.order_date BETWEEN TO_DATE(‘2025-01-01’, ‘YYYY-MM-DD’) AND TO_DATE(‘2025-01-31’, ‘YYYY-MM-DD’);
Explained.
SQL> SELECT * FROM TABLE(dbms_xplan.display);
PLAN_TABLE_OUTPUT
—————————————-
Plan hash value: 1234567890
——————————————————————————-
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
——————————————————————————-
| 0 | SELECT STATEMENT | | 10000 | 500K| 2000 (5)| 00:00:01 |
| 1 | DISTRIBUTED QUERY COORDINATOR | | | | | |
| 2 | DISTRIBUTED QUERY EXECUTION | | 10000 | 500K| 2000 (5)| 00:00:01 |
| 3 | HASH JOIN | | 10000 | 500K| 1000 (5)| 00:00:01 |
| 4 | TABLE ACCESS FULL | ORDERS | 10000 | 250K| 500 (5)| 00:00:01 |
| 5 | TABLE ACCESS FULL | CUSTOMERS | 50000 | 1250K| 400 (5)| 00:00:01 |
——————————————————————————-
# 测试查询性能
SQL> SET TIMING ON
SQL> SELECT o.order_id, o.order_date, c.customer_name, o.amount
2 FROM fgedu.orders o
3 JOIN fgedu.customers c ON o.customer_id = c.customer_id
4 WHERE o.order_date BETWEEN TO_DATE(‘2025-01-01’, ‘YYYY-MM-DD’) AND TO_DATE(‘2025-01-31’, ‘YYYY-MM-DD’);
Elapsed: 00:00:05.45
# 4. 处理措施
# 重新分布数据
SQL> ALTER TABLE fgedu.orders REPARTITION BY RANGE (order_date) (
2 PARTITION p202501 VALUES LESS THAN (TO_DATE(‘2025-02-01’, ‘YYYY-MM-DD’)),
3 PARTITION p202502 VALUES LESS THAN (TO_DATE(‘2025-03-01’, ‘YYYY-MM-DD’)),
4 PARTITION p202503 VALUES LESS THAN (TO_DATE(‘2025-04-01’, ‘YYYY-MM-DD’)),
5 PARTITION p202504 VALUES LESS THAN (TO_DATE(‘2025-05-01’, ‘YYYY-MM-DD’)),
6 PARTITION p202505 VALUES LESS THAN (TO_DATE(‘2025-06-01’, ‘YYYY-MM-DD’))
7 ) NODEGROUP (node1, node2, node3, node4, node5);
SQL> ALTER TABLE fgedu.customers REPARTITION BY HASH (customer_id) PARTITIONS 5 NODEGROUP (node1, node2, node3, node4, node5);
# 创建本地索引
SQL> CREATE INDEX idx_orders_order_date ON fgedu.orders(order_date) LOCAL;
SQL> CREATE INDEX idx_customers_customer_id ON fgedu.customers(customer_id) LOCAL;
# 优化查询语句
SQL> EXPLAIN PLAN FOR
2 SELECT /*+ PARALLEL(8) */ o.order_id, o.order_date, c.customer_name, o.amount
3 FROM fgedu.orders o
4 JOIN fgedu.customers c ON o.customer_id = c.customer_id
5 WHERE o.order_date BETWEEN TO_DATE(‘2025-01-01’, ‘YYYY-MM-DD’) AND TO_DATE(‘2025-01-31’, ‘YYYY-MM-DD’);
Explained.
SQL> SELECT * FROM TABLE(dbms_xplan.display);
PLAN_TABLE_OUTPUT
—————————————-
Plan hash value: 9876543210
——————————————————————————-
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
——————————————————————————-
| 0 | SELECT STATEMENT | | 10000 | 500K| 500 (5)| 00:00:01 |
| 1 | DISTRIBUTED QUERY COORDINATOR | | | | | |
| 2 | DISTRIBUTED QUERY EXECUTION | | 10000 | 500K| 500 (5)| 00:00:01 |
| 3 | HASH JOIN | | 10000 | 500K| 250 (5)| 00:00:01 |
| 4 | TABLE ACCESS BY INDEX ROWID| ORDERS | 10000 | 250K| 100 (5)| 00:00:01 |
| 5 | INDEX RANGE SCAN | IDX_ORDERS_ORDER_DATE | 10000 | | 50 (5)| 00:00:01 |
| 6 | TABLE ACCESS BY INDEX ROWID| CUSTOMERS | 10000 | 250K| 100 (5)| 00:00:01 |
| 7 | INDEX RANGE SCAN | IDX_CUSTOMERS_CUSTOMER_ID | 10000 | | 50 (5)| 00:00:01 |
——————————————————————————-
# 5. 验证结果
# 测试查询性能
SQL> SET TIMING ON
SQL> SELECT /*+ PARALLEL(8) */ o.order_id, o.order_date, c.customer_name, o.amount
2 FROM fgedu.orders o
3 JOIN fgedu.customers c ON o.customer_id = c.customer_id
4 WHERE o.order_date BETWEEN TO_DATE(‘2025-01-01’, ‘YYYY-MM-DD’) AND TO_DATE(‘2025-01-31’, ‘YYYY-MM-DD’);
Elapsed: 00:00:00.89
# 对比优化前后的性能
# 优化前：Elapsed: 00:00:05.45
# 优化后：Elapsed: 00:00:00.89
# 检查节点负载
$ ssh node1 “top -b -n 1 | grep Cpu”
Cpu(s): 15.2%us, 3.2%sy, 0.0%ni, 81.5%id, 0.0%wa, 0.0%hi, 0.1%si, 0.0%st
$ ssh node2 “top -b -n 1 | grep Cpu”
Cpu(s): 14.8%us, 3.1%sy, 0.0%ni, 81.9%id, 0.0%wa, 0.0%hi, 0.2%si, 0.0%st
$ ssh node3 “top -b -n 1 | grep Cpu”
Cpu(s): 15.1%us, 3.3%sy, 0.0%ni, 81.5%id, 0.0%wa, 0.0%hi, 0.1%si, 0.0%st
$ ssh node4 “top -b -n 1 | grep Cpu”
Cpu(s): 14.9%us, 3.2%sy, 0.0%ni, 81.7%id, 0.0%wa, 0.0%hi, 0.2%si, 0.0%st
$ ssh node5 “top -b -n 1 | grep Cpu”
Cpu(s): 15.3%us, 3.4%sy, 0.0%ni, 81.2%id, 0.0%wa, 0.0%hi, 0.1%si, 0.0%st
# 6. 预防措施
# 定期监控节点负载
– 定期检查节点负载情况，确保负载均衡
– 及时调整数据分布，避免某些节点过载
# 优化查询设计
– 合理使用并行查询，提高并发处理能力
– 优化连接操作，减少网络传输
– 合理使用索引，提高查询效率
# 系统配置优化
– 优化网络配置，提高网络带宽
– 合理配置内存，提高查询性能
– 优化I/O配置，提高数据访问速度
4.3 YashanDB分布式查询优化案例三
案例背景：某金融系统需要处理复杂的分布式查询，需要通过优化来提高查询性能。
# 1. 环境信息
– 数据库版本：YashanDB 19c
– 操作系统：Oracle Linux 9.3
– 硬件配置：4节点集群，每节点12核CPU，48GB内存，1.5TB SSD
– 业务类型：OLAP，金融分析
# 2. 问题描述
– 复杂分布式查询性能不佳，查询响应时间长
– 数据传输量大，网络开销高
– 查询计划不合理，导致性能瓶颈
# 3. 故障排查
# 查看查询执行计划
SQL> EXPLAIN PLAN FOR
2 SELECT t.transaction_id, t.trans_date, t.amount, c.customer_name, p.product_name
3 FROM fgedu.transactions t
4 JOIN fgedu.customers c ON t.customer_id = c.customer_id
5 JOIN fgedu.products p ON t.product_id = p.product_id
6 WHERE t.trans_date BETWEEN TO_DATE(‘2025-01-01’, ‘YYYY-MM-DD’) AND TO_DATE(‘2025-01-31’, ‘YYYY-MM-DD’)
7 AND t.amount > 1000
8 ORDER BY t.trans_date DESC;
Explained.
SQL> SELECT * FROM TABLE(dbms_xplan.display);
PLAN_TABLE_OUTPUT
—————————————-
Plan hash value: 1234567890
——————————————————————————-
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
——————————————————————————-
| 0 | SELECT STATEMENT | | 5000 | 500K| 5000 (5)| 00:00:01 |
| 1 | SORT ORDER BY | | 5000 | 500K| 5000 (5)| 00:00:01 |
| 2 | DISTRIBUTED QUERY COORDINATOR | | | | | |
| 3 | DISTRIBUTED QUERY EXECUTION | | 5000 | 500K| 4000 (5)| 00:00:01 |
| 4 | HASH JOIN | | 5000 | 500K| 3000 (5)| 00:00:01 |
| 5 | HASH JOIN | | 5000 | 350K| 2000 (5)| 00:00:01 |
| 6 | TABLE ACCESS FULL | TRANSACTIONS | 5000 | 200K| 1000 (5)| 00:00:01 |
| 7 | TABLE ACCESS FULL | CUSTOMERS | 50000 | 1250K| 500 (5)| 00:00:01 |
| 8 | TABLE ACCESS FULL | PRODUCTS | 10000 | 300K| 500 (5)| 00:00:01 |
——————————————————————————-
# 测试查询性能
SQL> SET TIMING ON
SQL> SELECT t.transaction_id, t.trans_date, t.amount, c.customer_name, p.product_name
2 FROM fgedu.transactions t
3 JOIN fgedu.customers c ON t.customer_id = c.customer_id
4 JOIN fgedu.products p ON t.product_id = p.product_id
5 WHERE t.trans_date BETWEEN TO_DATE(‘2025-01-01’, ‘YYYY-MM-DD’) AND TO_DATE(‘2025-01-31’, ‘YYYY-MM-DD’)
6 AND t.amount > 1000
7 ORDER BY t.trans_date DESC;
Elapsed: 00:00:15.67
# 4. 处理措施
# 重新分布数据
SQL> ALTER TABLE fgedu.transactions REPARTITION BY RANGE (trans_date) (
2 PARTITION p202501 VALUES LESS THAN (TO_DATE(‘2025-02-01’, ‘YYYY-MM-DD’)),
3 PARTITION p202502 VALUES LESS THAN (TO_DATE(‘2025-03-01’, ‘YYYY-MM-DD’)),
4 PARTITION p202503 VALUES LESS THAN (TO_DATE(‘2025-04-01’, ‘YYYY-MM-DD’)),
5 PARTITION p202504 VALUES LESS THAN (TO_DATE(‘2025-05-01’, ‘YYYY-MM-DD’))
6 ) NODEGROUP (node1, node2, node3, node4);
# 创建本地索引
SQL> CREATE INDEX idx_transactions_trans_date ON fgedu.transactions(trans_date) LOCAL;
SQL> CREATE INDEX idx_transactions_amount ON fgedu.transactions(amount) LOCAL;
SQL> CREATE INDEX idx_transactions_customer_id ON fgedu.transactions(customer_id) LOCAL;
SQL> CREATE INDEX idx_transactions_product_id ON fgedu.transactions(product_id) LOCAL;
# 优化查询语句
SQL> EXPLAIN PLAN FOR
2 SELECT /*+ PARALLEL(6) */ t.transaction_id, t.trans_date, t.amount, c.customer_name, p.product_name
3 FROM fgedu.transactions t
4 JOIN fgedu.customers c ON t.customer_id = c.customer_id
5 JOIN fgedu.products p ON t.product_id = p.product_id
6 WHERE t.trans_date BETWEEN TO_DATE(‘2025-01-01’, ‘YYYY-MM-DD’) AND TO_DATE(‘2025-01-31’, ‘YYYY-MM-DD’)
7 AND t.amount > 1000
8 ORDER BY t.trans_date DESC;
Explained.
SQL> SELECT * FROM TABLE(dbms_xplan.display);
PLAN_TABLE_OUTPUT
—————————————-
Plan hash value: 9876543210
——————————————————————————-
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
——————————————————————————-
| 0 | SELECT STATEMENT | | 5000 | 500K| 1000 (5)| 00:00:01 |
| 1 | SORT ORDER BY | | 5000 | 500K| 1000 (5)| 00:00:01 |
| 2 | DISTRIBUTED QUERY COORDINATOR | | | | | |
| 3 | DISTRIBUTED QUERY EXECUTION | | 5000 | 500K| 800 (5)| 00:00:01 |
| 4 | HASH JOIN | | 5000 | 500K| 600 (5)| 00:00:01 |
| 5 | HASH JOIN | | 5000 | 350K| 400 (5)| 00:00:01 |
| 6 | TABLE ACCESS BY INDEX ROWID| TRANSACTIONS | 5000 | 200K| 100 (5)| 00:00:01 |
| 7 | BITMAP CONVERSION TO ROWIDS| | | | | |
| 8 | BITMAP AND | | | | | |
| 9 | BITMAP INDEX RANGE SCAN| IDX_TRANSACTIONS_TRANS_DATE | | | | |
| 10 | BITMAP INDEX RANGE SCAN| IDX_TRANSACTIONS_AMOUNT | | | | |
| 11 | TABLE ACCESS BY INDEX ROWID| CUSTOMERS | 5000 | 150K| 100 (5)| 00:00:01 |
| 12 | INDEX RANGE SCAN | IDX_CUSTOMERS_CUSTOMER_ID | 5000 | | 50 (5)| 00:00:01 |
| 13 | TABLE ACCESS BY INDEX ROWID| PRODUCTS | 5000 | 150K| 100 (5)| 00:00:01 |
| 14 | INDEX RANGE SCAN | IDX_PRODUCTS_PRODUCT_ID | 5000 | | 50 (5)| 00:00:01 |
——————————————————————————-
# 5. 验证结果
# 测试查询性能
SQL> SET TIMING ON
SQL> SELECT /*+ PARALLEL(6) */ t.transaction_id, t.trans_date, t.amount, c.customer_name, p.product_name
2 FROM fgedu.transactions t
3 JOIN fgedu.customers c ON t.customer_id = c.customer_id
4 JOIN fgedu.products p ON t.product_id = p.product_id
5 WHERE t.trans_date BETWEEN TO_DATE(‘2025-01-01’, ‘YYYY-MM-DD’) AND TO_DATE(‘2025-01-31’, ‘YYYY-MM-DD’)
6 AND t.amount > 1000
7 ORDER BY t.trans_date DESC;
Elapsed: 00:00:02.34
# 对比优化前后的性能
# 优化前：Elapsed: 00:00:15.67
# 优化后：Elapsed: 00:00:02.34
# 检查网络传输
$ netstat -tunap | grep 1521 | wc -l
12
# 6. 预防措施
# 定期监控查询性能
– 定期监控复杂查询的性能，及时发现问题
– 定期分析执行计划，找出性能瓶颈
# 优化查询设计
– 合理使用索引，提高查询效率
– 优化连接操作，减少网络传输
– 合理使用并行查询，提高查询性能
# 系统配置优化
– 优化网络配置，提高网络带宽
– 合理配置内存，提高查询性能
– 优化I/O配置，提高数据访问速度
Part05-风哥经验总结与分享
5.1 YashanDB分布式查询优化经验总结
YashanDB分布式查询优化经验总结：
- 合理数据分布：合理分布数据，减少节点之间的数据传输
- 优化查询计划：优化查询计划，选择最佳执行策略
- 充分利用并行：充分利用并行执行，提高查询性能
- 合理使用索引：合理使用索引，提高查询效率
- 优化网络配置：优化网络配置，减少网络延迟
- 平衡节点负载：平衡各个节点的负载，避免某些节点过载
- 定期监控和调优：定期监控分布式查询的执行情况，及时调整优化策略
- 故障处理机制：建立完善的故障处理机制，确保查询的可靠性
5.2 YashanDB分布式查询优化检查清单
– [ ] 数据分布是否合理
– [ ] 查询计划是否优化
– [ ] 并行执行是否配置
– [ ] 索引是否合理使用
– [ ] 网络配置是否优化
– [ ] 节点负载是否平衡
– [ ] 监控机制是否建立
– [ ] 故障处理机制是否完善
– [ ] 性能是否定期评估
– [ ] 优化策略是否定期调整
# 分布式查询维护检查清单
– [ ] 数据分布是否定期检查
– [ ] 查询性能是否定期监控
– [ ] 节点状态是否定期检查
– [ ] 网络连接是否定期检查
– [ ] 索引是否定期维护
– [ ] 统计信息是否定期收集
– [ ] 系统参数是否定期调整
– [ ] 备份和恢复是否定期测试
5.3 YashanDB分布式查询优化工具推荐
YashanDB分布式查询优化常用工具：
- 数据库工具：SQL*Plus、SQL Developer、PL/SQL Developer
- 诊断工具：EXPLAIN PLAN、DBMS_XPLAN、DBMS_DISTRIBUTED
- 监控工具：Enterprise Manager、Prometheus + Grafana、Zabbix
- 性能分析工具：AWR、ASH、ADDM、SQL Tuning Advisor
- 网络工具：ping、traceroute、netstat
- 系统工具：top、iostat、vmstat
- 第三方工具：Toad、Navicat、Oracle SQL Developer
本文由风哥教程整理发布,仅用于学习测试使用,转载注明出处:http://www.fgedu.net.cn/10327.html
联系我们
在线咨询：
微信号：itpux-com
工作日：9:30-18:30，节假日休息
