前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
社区首页 >专栏 >OceanBase初体验之查看OceanBase的执行计划

OceanBase初体验之查看OceanBase的执行计划

作者头像
HOHO
发布于 2024-03-18 00:03:06
发布于 2024-03-18 00:03:06
11600
代码可运行
举报
运行总次数:0
代码可运行

前置条件

  • 包含obd和obclient的中控机
  • OceanBase 测试集群
  • 独立的测试租户
  • BenchmarkSQL 工具(可选)

为了能够方面的查看复杂SQL的执行计划,我们先用TPCC模拟一些数据库负载。

模拟数据库负载

obd里面已经集成了tpcc测试工具,需要联网更新一下插件即可。如果机器不具备外网环境,需要提前下载BenchmarkSQL上传到测试机中。

BenchmarkSQL下载地址:https://github.com/meiq4096/benchmarksql-5.0

这里直接用obd里的tpcc,操作比较简单:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
[ob@localhost ~]$ sudo yum install -y yum-utils
[ob@localhost ~]$ sudo yum-config-manager --add-repo https://mirrors.aliyun.com/oceanbase/OceanBase.repo
[ob@localhost ~]$ sudo yum install obtpcc java

在前面新建的tt租户下跑一个10仓的负载,时间是5分钟:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
[ob@localhost ~]$ obd test tpcc obtest --tenant=tt --warehouses 10  --run-mins 5
Get local repositories and plugins ok
Open ssh connection ok
Cluster status check ok
Connect obproxy(x.x.x.222:2883) ok
Connect obproxy(x.x.x.222:2883) ok
Optimize for stage build ok
Connect to tenant tt ok
Server check ok
Merge ok
Starting BenchmarkSQL LoadData

driver=com.mysql.jdbc.Driver
conn=jdbc:mysql://x.x.x.222:2883/test?rewriteBatchedStatements=true&allowMultiQueries=true&useLocalSessionState=true&useUnicode=true&characterEncoding=utf-8&socketTimeout=30000000&useSSL=false
user=root@tt
password=***********
warehouses=10
loadWorkers=1
fileLocation (not defined)
csvNullValue (not defined - using default 'NULL')

Worker 000: Loading ITEM
Worker 000: Loading ITEM done
Worker 000: Loading Warehouse      1
Worker 000: Loading Warehouse      1 done
Worker 000: Loading Warehouse      2
Worker 000: Loading Warehouse      2 done
Worker 000: Loading Warehouse      3
Worker 000: Loading Warehouse      3 done
Worker 000: Loading Warehouse      4
Worker 000: Loading Warehouse      4 done
Worker 000: Loading Warehouse      5
Worker 000: Loading Warehouse      5 done
Worker 000: Loading Warehouse      6
Worker 000: Loading Warehouse      6 done
Worker 000: Loading Warehouse      7
Worker 000: Loading Warehouse      7 done
Worker 000: Loading Warehouse      8
Worker 000: Loading Warehouse      8 done
Worker 000: Loading Warehouse      9
Worker 000: Loading Warehouse      9 done
Worker 000: Loading Warehouse     10
Worker 000: Loading Warehouse     10 done
create index ok
finish build ok
check data ok
Optimize for stage test ok
Connect to tenant tt ok
Merge ok
14:20:27,866 [main] INFO   jTPCC : Term-00,
14:20:27,869 [main] INFO   jTPCC : Term-00, +-------------------------------------------------------------+
14:20:27,869 [main] INFO   jTPCC : Term-00,      BenchmarkSQL v5.0
14:20:27,869 [main] INFO   jTPCC : Term-00, +-------------------------------------------------------------+
14:20:27,869 [main] INFO   jTPCC : Term-00,  (c) 2003, Raul Barbosa
14:20:27,869 [main] INFO   jTPCC : Term-00,  (c) 2004-2016, Denis Lussier
14:20:27,872 [main] INFO   jTPCC : Term-00,  (c) 2016, Jan Wieck
14:20:27,872 [main] INFO   jTPCC : Term-00, +-------------------------------------------------------------+
14:20:27,872 [main] INFO   jTPCC : Term-00,
14:20:27,872 [main] INFO   jTPCC : Term-00, db=oceanbase
14:20:27,872 [main] INFO   jTPCC : Term-00, driver=com.mysql.jdbc.Driver
14:20:27,872 [main] INFO   jTPCC : Term-00, conn=jdbc:mysql://x.x.x.222:2883/test?rewriteBatchedStatements=true&allowMultiQueries=true&useLocalSessionState=true&useUnicode=true&characterEncoding=utf-8&socketTimeout=30000000&useSSL=false
14:20:27,872 [main] INFO   jTPCC : Term-00, user=root@tt
14:20:27,872 [main] INFO   jTPCC : Term-00,
14:20:27,872 [main] INFO   jTPCC : Term-00, warehouses=10
14:20:27,873 [main] INFO   jTPCC : Term-00, terminals=100
14:20:27,874 [main] INFO   jTPCC : Term-00, runMins=5
14:20:27,874 [main] INFO   jTPCC : Term-00, limitTxnsPerMin=0
14:20:27,874 [main] INFO   jTPCC : Term-00, terminalWarehouseFixed=true
14:20:27,874 [main] INFO   jTPCC : Term-00,
14:20:27,874 [main] INFO   jTPCC : Term-00, newOrderWeight=45
14:20:27,875 [main] INFO   jTPCC : Term-00, paymentWeight=43
14:20:27,875 [main] INFO   jTPCC : Term-00, orderStatusWeight=4
14:20:27,875 [main] INFO   jTPCC : Term-00, deliveryWeight=4
14:20:27,875 [main] INFO   jTPCC : Term-00, stockLevelWeight=4
14:20:27,875 [main] INFO   jTPCC : Term-00,
14:20:27,875 [main] INFO   jTPCC : Term-00, resultDirectory=my_result_%tY-%tm-%td_%tH%tM%tS
14:20:27,875 [main] INFO   jTPCC : Term-00, osCollectorScript=./misc/os_collector_linux.py
14:20:27,875 [main] INFO   jTPCC : Term-00,
14:20:27,891 [main] INFO   jTPCC : Term-00, copied /home/ob/tmp/props.oceanbase to my_result_2024-03-17_142027/run.properties
14:20:27,891 [main] INFO   jTPCC : Term-00, created my_result_2024-03-17_142027/data/runInfo.csv for runID 1
14:20:27,891 [main] INFO   jTPCC : Term-00, writing per transaction results to my_result_2024-03-17_142027/data/result.csv
14:20:27,892 [main] INFO   jTPCC : Term-00, osCollectorScript=./misc/os_collector_linux.py
14:20:27,892 [main] INFO   jTPCC : Term-00, osCollectorInterval=1
14:20:27,892 [main] INFO   jTPCC : Term-00, osCollectorSSHAddr=null
14:20:27,892 [main] INFO   jTPCC : Term-00, osCollectorDevices=null
14:20:27,953 [main] INFO   jTPCC : Term-00,
14:20:28,239 [main] INFO   jTPCC : Term-00, C value for C_LAST during load: 192                                                          Term-00, 14:25:29,121 [Thread-5] INFO   jTPCC : Term-00, mTOTAL: 1116984    Memory Usage: 95MB / 730MB                                                     14:25:29,121 [Thread-5] INFO   jTPCC : Term-00,                                                                                                   14:25:29,121 [Thread-5] INFO   jTPCC : Term-00, Measured tpmC (NewOrders) = 15185.13
14:25:29,121 [Thread-5] INFO   jTPCC : Term-00, Measured tpmTOTAL = 33746.42
14:25:29,121 [Thread-5] INFO   jTPCC : Term-00, Session Start     = 2024-03-17 14:20:28
14:25:29,121 [Thread-5] INFO   jTPCC : Term-00, Session End       = 2024-03-17 14:25:29
14:25:29,122 [Thread-5] INFO   jTPCC : Term-00, Transaction Count = 168883
TPC-C Result
Measured tpmC (NewOrders)   : 15185.13
Measured tpmTOTAL           : 33746.42
Session Start               : 2024-03-17 14:20:28
Session End                 : 2024-03-17 14:25:29
Transaction Count           : 168883

Recover ok
Trace ID: eeb13702-e424-11ee-aaa8-1c697a639d50
If you want to view detailed obd logs, please run: obd display-trace eeb13702-e424-11ee-aaa8-1c697a639d50

手动部署 BenchmarkSQL 主要步骤:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
git clone https://github.com/obpilot/benchmarksql-5.0.git
cd benchmarksql-5.0/run
vi props.ob  # 修改成实际的连接信息,设置主要运行参数
sh runSQL.sh props.ob sql.oceanbase/tableCreates.sql  # 创建表结构
sh runSQL.sh props.ob sql.oceanbase/indexCreates.sql  # 创建索引
sh runLoader.sh props.ob # 装载数据
sh runBenchmark.sh props.ob # 执行测试

跑tpcc时数据库的负载情况如下:

查找 TOP SQL

查询某段时间内请求次数排在 TOP N 的 SQL:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
SELECT/*+ PARALLEL(15)*/ SQL_ID,PLAN_ID, COUNT(*) AS QPS, AVG(t1.elapsed_time) RT 
                FROM oceanbase.GV$OB_SQL_AUDIT t1 WHERE tenant_id = 1002 AND 
                IS_EXECUTOR_RPC = 0 AND time_to_usec(DATE_SUB(current_timestamp, INTERVAL 10 MINUTE) ) AND
                request_time < time_to_usec (now()) 
                GROUP BY t1.sql_id ORDER BY QPS DESC LIMIT 10;
+----------------------------------+---------+------+----------+
| SQL_ID                           | PLAN_ID | QPS  | RT       |
+----------------------------------+---------+------+----------+
| A460265EC2F0763A15DD27CE9E4E2200 |    4518 | 4771 |  59.6087 |
| 7229213613983BC5FDA15AD11EC70D01 |    3206 | 1440 | 340.2958 |
| E1F2BDA1D7391B757859ED3704E5AFB7 |    3213 | 1440 | 125.9278 |
| 2B5697196EDFE9E97FA3384F581178F5 |    3214 | 1440 |  87.7139 |
| FFFCA4D67EA0A788813031B8BBC3B329 |       0 |  301 |  34.6412 |
| 54B5A5861DAF78F52D9ADFBEE83D35B5 |    3202 |  152 |  94.4276 |
| 7F4A525CC8F849F6527F4911CC4BC348 |    3189 |  152 | 121.2303 |
| BB01ECB7605AE31CBC65E6949D84B235 |    3195 |  152 | 220.9079 |
| E86A0CA8BE3F21A2FBC9F1F9855075A1 |    3184 |  152 | 824.8158 |
| FC3FED8CCB2946DE54F1C5BA3656023C |    3181 |  152 | 501.9671 |
+----------------------------------+---------+------+----------+
10 rows in set (0.012 sec)

查询某段时间内平均 执行时间 排在 TOP N 的 SQL(可根据执行时间定位慢SQL):

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
SELECT/*+ PARALLEL(15)*/ SQL_ID,PLAN_ID, COUNT(*) AS QPS, AVG(t1.elapsed_time) RT   
                FROM oceanbase.GV$OB_SQL_AUDIT t1   
                WHERE tenant_id = 1002 AND IS_EXECUTOR_RPC = 0    
                AND request_time > time_to_usec(DATE_SUB(current_timestamp, INTERVAL 10 MINUTE) )
                GROUP BY t1.sql_id ORDER BY RT DESC LIMIT 10;

根据sql_id找到对应的SQL文本:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
obclient [(none)]> select query_sql from oceanbase.GV$OB_PLAN_CACHE_PLAN_STAT where sql_id='A460265EC2F0763A15DD27CE9E4E2200';
+---------------------------------------------------------------------------+
| query_sql                                                                 |
+---------------------------------------------------------------------------+
| SELECT i_price, i_name, i_data     FROM bmsql_item     WHERE i_id = 14972 |
+---------------------------------------------------------------------------+
1 row in set (0.005 sec)

分析执行计划

我们获取平均执行时间最长的三条SQL,分析他们的实际执行计划和解析执行计划。

先找出TOP SQL:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
obclient [(none)]> SELECT/*+ PARALLEL(15)*/ SQL_ID,PLAN_ID, COUNT(*) AS QPS, AVG(t1.elapsed_time) RT
    ->                 FROM oceanbase.GV$OB_SQL_AUDIT t1
    ->                 WHERE tenant_id = 1002 AND IS_EXECUTOR_RPC = 0
    ->                 AND request_time > time_to_usec(DATE_SUB(current_timestamp, INTERVAL 10 MINUTE) )
    ->                 GROUP BY t1.sql_id ORDER BY RT DESC LIMIT 3;
+----------------------------------+---------+------+------------+
| SQL_ID                           | PLAN_ID | QPS  | RT         |
+----------------------------------+---------+------+------------+
| 89B757D18634B472A21A0EB8EB83ECE3 |    4035 |    1 | 11747.0000 |
| F59A700FA168324279B0DBC25E19760F |    3217 |    8 |  5686.6250 |
| C9FA41444B84AF63AD4FB24B9252F1A6 |    4025 |    7 |  2694.7143 |
+----------------------------------+---------+------+------------+
3 rows in set (0.012 sec)

第一条sql_id找出对应的SQL文本,再手动获取执行计划:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
obclient [tpcc]> explain SELECT count(*) AS low_stock FROM (    SELECT s_w_id, s_i_id, s_quantity         FROM bmsql_stock         WHERE s_w_id = 4 AND s_quantity < 17 AND s_i_id IN (            SELECT ol_i_id                 FROM bmsql_district                 JOIN bmsql_order_line ON ol_w_id = d_w_id                  AND ol_d_id = d_id                  AND ol_o_id >= d_next_o_id - 20                  AND ol_o_id < d_next_o_id                 WHERE d_w_id = 4 AND d_id = 9         )     ) ;
+----------------------------------------------------------------------------------------------------------------------------------------------------------+
| Query Plan                                                                                                                                               |
+----------------------------------------------------------------------------------------------------------------------------------------------------------+
| ================================================================================                                                                         |
| |ID|OPERATOR                            |NAME            |EST.ROWS|EST.TIME(us)|                                                                         |
| --------------------------------------------------------------------------------                                                                         |
| |0 |SCALAR GROUP BY                     |                |1       |269         |                                                                         |
| |1 |└─HASH RIGHT SEMI JOIN              |                |15      |269         |                                                                         |
| |2 |  ├─SUBPLAN SCAN                    |VIEW1           |15      |24          |                                                                         |
| |3 |  │ └─NESTED-LOOP JOIN              |                |15      |24          |                                                                         |
| |4 |  │   ├─TABLE GET                   |bmsql_district  |1       |3           |                                                                         |
| |5 |  │   └─DISTRIBUTED TABLE RANGE SCAN|bmsql_order_line|1       |21          |                                                                         |
| |6 |  └─TABLE RANGE SCAN                |bmsql_stock     |1035    |156         |                                                                         |
| ================================================================================                                                                         |
| Outputs & filters:                                                                                                                                       |
| -------------------------------------                                                                                                                    |
|   0 - output([T_FUN_COUNT(*)]), filter(nil), rowset=256                                                                                                  |
|       group(nil), agg_func([T_FUN_COUNT(*)])                                                                                                             |
|   1 - output(nil), filter(nil), rowset=256                                                                                                               |
|       equal_conds([bmsql_stock.s_i_id = VIEW1.ol_i_id]), other_conds(nil)                                                                                |
|   2 - output([VIEW1.ol_i_id]), filter(nil), rowset=256                                                                                                   |
|       access([VIEW1.ol_i_id])                                                                                                                            |
|   3 - output([bmsql_order_line.ol_i_id]), filter(nil), rowset=256                                                                                        |
|       conds(nil), nl_params_([bmsql_district.d_next_o_id(:0)]), use_batch=false                                                                          |
|   4 - output([bmsql_district.d_next_o_id]), filter([bmsql_district.d_next_o_id > bmsql_district.d_next_o_id - 20]), rowset=256                           |
|       access([bmsql_district.d_next_o_id]), partitions(p0)                                                                                               |
|       is_index_back=false, is_global_index=false, filter_before_indexback[false],                                                                        |
|       range_key([bmsql_district.d_w_id], [bmsql_district.d_id]), range[4,9 ; 4,9],                                                                       |
|       range_cond([bmsql_district.d_w_id = 4], [bmsql_district.d_id = 9])                                                                                 |
|   5 - output([bmsql_order_line.ol_i_id]), filter(nil), rowset=256                                                                                        |
|       access([bmsql_order_line.ol_i_id]), partitions(p0)                                                                                                 |
|       is_index_back=false, is_global_index=false,                                                                                                        |
|       range_key([bmsql_order_line.ol_w_id], [bmsql_order_line.ol_d_id], [bmsql_order_line.ol_o_id], [bmsql_order_line.ol_number]), range(MIN ; MAX),     |
|       range_cond([bmsql_order_line.ol_w_id = 4], [bmsql_order_line.ol_d_id = 9], [bmsql_order_line.ol_o_id >= :0 - 20], [bmsql_order_line.ol_o_id < :0]) |
|   6 - output([bmsql_stock.s_i_id]), filter([bmsql_stock.s_quantity < 17]), rowset=256                                                                    |
|       access([bmsql_stock.s_i_id], [bmsql_stock.s_quantity]), partitions(p0)                                                                             |
|       is_index_back=false, is_global_index=false, filter_before_indexback[false],                                                                        |
|       range_key([bmsql_stock.s_w_id], [bmsql_stock.s_i_id]), range(4,MIN ; 4,MAX),                                                                       |
|       range_cond([bmsql_stock.s_w_id = 4])                                                                                                               |
+----------------------------------------------------------------------------------------------------------------------------------------------------------+
36 rows in set (0.088 sec)

它的真实执行计划:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
select * from oceanbase.V$OB_PLAN_CACHE_PLAN_EXPLAIN where tenant_id=1002 and  plan_id=3217 ;

执行计划重要信息:

  • OPERATOR,算子的名称,比如全表扫描TABLE SCAN,真实执行计划会加上PHY_前缀
  • NAME,算子操作的对象名称,比如表名、索引名等
  • ROWS,真实执行计划里面代表实际数据行数,explain里面代表估算的行数(EST.ROWS)
  • COST,算子执行时间,单位是微秒,explain里面的EST.TIME为估算时间
  • PROPERTY,算子执行的详细过程

这里在查询执行计划时有一个坑要注意,oceanbase.V$OB_PLAN_CACHE_PLAN_EXPLAIN视图只能在SQL执行的observer节点上查询,因为PLAN CACHE是按节点缓存的,通过obproxy登录的话往往查不到想要的数据,要直连observer。

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2024-03-17,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
PostgreSQL从小白到高手教程 - 第45讲:poc-tpcc测试
PostgreSQL从小白到专家,是从入门逐渐能力提升的一个系列教程,内容包括对PG基础的认知、包括安装使用、包括角色权限、包括维护管理、、等内容,希望对热爱PG、学习PG的同学们有帮助,欢迎持续关注CUUG PG技术大讲堂。
用户5892232
2024/02/29
1620
PostgreSQL从小白到高手教程 - 第45讲:poc-tpcc测试
YashanDB TPC-C 测试介绍
本章节将介绍在 YashanDB 单机数据库上运行基于 BenchmarkSQL 的 TPC-C 测试的具体操作及相关示例。
用户10349277
2025/03/06
780
【TPC-C】TPC-C标准化基准测试设计RDBMS的相关表结构
TPC 是事务处理性能委员会组织,该委员会致力于制定和维护一系列标准化的基准测试,以评估商业计算系统的性能。其中最著名的是一系列用于评估计算机系统性能的基准测试。
SarPro
2024/05/24
7470
【TPC-C】TPC-C标准化基准测试设计RDBMS的相关表结构
NL连接一定是小表驱动大表效率高吗
两表使用nest loop(以下简称NL)方式进行连接,小表驱动大表效率高,这似乎是大家的共识,但事实上这是有条件的,并不总是成立。这主要看大表扫描关联字段索引后返回多少数据量,是否需要回表,如果大表关联后返回大量数据,然后再回表,这个代价就会很高,大表处于被驱动表的位置可能就不是最佳选择了。
GreatSQL社区
2023/02/22
4830
技术分享 | OB 慢查询排查思路
本文汇总了项目实践中前辈的经验和笔者的理解,旨在帮助初学 OceanBase(以下简称 OB)的工程师,快速解决 SQL 执行缓慢等性能问题。当遇到性能问题时,很多工程师可能会感到无从下手,本文将根据关键日志提供多种分析方向,以加速问题排查。
爱可生开源社区
2023/05/25
8320
故障分析 | OceanBase 频繁更新数据后读性能下降的排查
本文分析并复现了 OceanBase 频繁更新数据后读性能下降现象的原因,并给出了性能改善建议。
爱可生开源社区
2023/05/15
4260
故障分析 | OceanBase 频繁更新数据后读性能下降的排查
【DB宝85】 OceanBase Docker安装体验
参考:https://www.xmmup.com/dbbao2centos7anzhuangdocker.html
AiDBA宝典
2022/02/23
1K0
【DB宝85】 OceanBase Docker安装体验
一文搞懂 OceanBase 4.x 全链路追踪
当出现超时问题时,往往无法快速定位是 OceanBase 内部组件的问题 还是 网络的问题。运维人员只能根据经验和 observer 日志进行分析。
爱可生开源社区
2025/04/16
1020
一文搞懂 OceanBase 4.x 全链路追踪
Oracle 执行计划查看方法汇总及优劣比较
执行计划是一条 SQL 语句在 Oracle 数据库中的执行过程或访问路径的描述。如下图所示,是一个比较完整的执行计划示意图。
JiekeXu之路
2022/12/07
1.5K0
Oracle 执行计划查看方法汇总及优劣比较
OceanBase初体验之从MySQL迁移数据到OceanBase集群
先在源端 MySQL 用如下脚本创建测试表,以及写入10000条数据用于迁移测试。
HOHO
2024/03/18
2250
Oracle优化器之自适应执行计划(Adaptive Execution Plans)
我们知道在12c之前的版本,虽然有ACS、CFB等功能通过在SQL文执行时收集信息,来改善SQL文再次执行时的执行计划,但是在SQL文第一次执行时,只能根据统计信息做成的执行计划执行SQL,在执行过程中并不能改变。 如果统计信息不准确,访问的数据行数非常大并且选择的执行计划不是最优时,在SQL文第一次执行时可能会引起在灾难性的性能问题。
SQLplusDB
2020/03/26
1.3K0
如何使用coe_xfr_sql_profile绑定手工新生成的执行计划
coe_xfr_sql_profile.sql脚本网上找 1.原来的执行计划,走全表,direct path readSELECT 'ext.vivo.vivoIssue.model.ActivityRecords', A0.approveNO, A0.roleName, TO_CHAR (A0.createStampA2, 'dd mm yyyy hh24:mi:ss'), A0.markForDeleteA2, TO_CHAR (A0.modi
lemotree
2022/06/21
8230
Oceanbase试用版部署安装(Linux 平台上部署)
1.官方建议使用CentOS 6 或 CentOS 7,部署脚本只在这两个发行版上试验过。
Lucifer三思而后行
2021/08/17
1.7K0
Oracle 历史SQL语句执行计划的对比与分析
    基于CBO优化器的环境中,SQL执行计划的生成依赖于统计信息的真实与完整。如列的离散度,列上的直方图,索引的可用性,索引上的聚簇因子。当这些信息是真实完整的情况下,CBO优化器通常都可以制定最优的执行计划。也正因此CBO优化器也灵活,难以控制,任一信息的不真实或缺失都可能导致执行计划发生变化而产生多个版本。经常碰到的情形是之前的某个SQL语句前阵子还不是TOP SQL,而最近变成了TOP SQL。或者说之前尽管是TOP SQL但,但最近尽然成了TOP 1。对于此情形,我们可以比对SQL语句的历史执行计划进行分析是何种原因导致SQL变慢或执行计划发生变化。下面通过例子来模拟SQL执行计划变异的情形。 1、创建演示环境
Leshami
2018/08/13
1.2K0
供收藏:Oracle固定SQL执行计划的方法总结
Oracle数据库中执行sql的时候,优化器会根据优化器统计信息和一些参数来生成“它认为最好的“执行计划。
SQLplusDB
2022/08/19
1.4K0
查看SQL执行计划的方法及优劣
作者 | 胡佳伟:云和恩墨技术工程师,有多年数据库优化经验,在一线执行过多个包括通信、保险等行业的优化项目。
数据和云
2018/07/27
1.2K0
查看SQL执行计划的方法及优劣
Oracle AWR 阙值影响历史执行计划
      最近有网友提到为什么在dba_hist_sql_plan中无法查看到sql语句的历史执行计划,对于这个问题是由于缺省情况下,Oracle 设定的阙值并非捕获所有的sql语句,所以无法看到某些sql历史执行计划乃正常现象。在Oracle 9i的时候,我们可以通过设定不同的快照level获得不同程度的详细信息。也可以单独配置收集sql的阙值,如指定sql的执行次数,磁盘读的次数,解析调用的数量等。所有超出这个设置的sql语句都收集到snapshot之中。Oracle 10g,11g也有相应的设置。下面来描述这个问题。
Leshami
2018/08/14
6780
源码阅读OceanBase(1)计划开始
https://wangcy6.github.io/post/plan/oceanbase_day1/
早起的鸟儿有虫吃
2021/07/22
9570
Oracle获取执行计划的方法(六脉神剑)
优点:可以通过STRATS得出表被访问次数;可以通过E-Rows和A-Rows来判断预测行数和实际行数是否一致;可以通过Buffers来获取逻辑读数值。
Lucifer三思而后行
2021/08/17
6340
Oracle获取执行计划的方法(六脉神剑)
为什么预估执行计划与真实执行计划会有差异?
一 问题概要 对同一个 SQL 语句的 ExplainPlan 里显示的预估执行计划与通过 V$SQL_PLAN 视图获取的 Runtime Plan 真实执行计划,偶尔会发现两边有不一致的情况,为什么呢?为什么预估执行计划会不准确?怎样才能避免这种情况的发生? 二 问题解答 这是执行计划相关中会被经常问道的问题,也是困扰自己很长时间的问题。希望通过下面的分析能解释一部分原因。 对同一个 SQL 语句的 ExplainPlan 里显示的预估执行计划与通过 V$SQL_PLAN 视图获取的真实执行计划不
数据和云
2018/04/17
8550
为什么预估执行计划与真实执行计划会有差异?
推荐阅读
相关推荐
PostgreSQL从小白到高手教程 - 第45讲:poc-tpcc测试
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档
本文部分代码块支持一键运行,欢迎体验
本文部分代码块支持一键运行,欢迎体验