---
title: Table 数据量相同的两个环境，相同执行计划的 SQL 执行性能差异较大的原因-OceanBase数据库使用指南
description: 了解OceanBase数据库在实际应用中关于 Table 数据量相同的两个环境，相同执行计划的 SQL 执行性能差异较大的原因相关的常见问题和使用技巧，帮助您快速解决 Table 数据量相同的两个环境，相同执行计划的 SQL 执行性能差异较大的原因的难题。
---
切换语言

- 中文站 - 简体中文
- International - English
- 日本站 - 日本語

划线反馈

# Table 数据量相同的两个环境，相同执行计划的 SQL 执行性能差异较大的原因

更新时间：2026-05-14 07:41

适用版本： V2.1.x、V2.2.x、V3.1.x、V3.2.x 内容类型：Troubleshoot  

## 适用版本

OceanBase 数据库 V2.x 和 V3.x 版本。

## 问题描述

在两个数据量相同的环境下，同样的 SQL 使用相同的执行计划，其执行性能相差较大。在测试环境执行耗时 700ms，而在生产环境执行 3s+。

## 问题原因

对比 `SQL_AUDIT`，生产环境的 SQL 执行中 `SSSTORE_READ_ROW_COUNT` 的数量远大于测试环境，导致 SQL 执行效率差。

![Alt text](https://file.oceanbase.com/doc/img/knowledge-base/database/performance/sql1.png)

![Alt text](https://file.oceanbase.com/doc/img/knowledge-base/database/performance/sql2.png)

在 OceanBase 数据库 V2.x、V3.x 中，当 SSTable 中的微块数据和增量没有交叉时，可以直接把过滤条件下压到微块层，直接过滤掉不需要的数据，就不会扫上来。

生产环境中存在频繁的数据更新操作，MemTable 与 Major SSTable 中有交叉的数据，无法使用上述优化策略，需要将数据一行一行扫上来。而测试环境没有更新数据，所以就能直接优化扫描路径。从而导致了性能的差异。

## 解决方法

可以采用以下策略来进行优化。

1. 业务上避免更新删除要查询的数据，或者业务上可以把更新删除放到每日合并前面执行。
 2. 将表改成 queuing 表，采取激进的分区级合并调度。

上一篇

[同一条 SQL 使用不同的参数执行时快时慢](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000340643)

下一篇

[batch insert 大量硬解析问题的原因和解决方法](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000002396931) ![有帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*y6ocSqN8cqsAAAAAAAAAAAAAARQnAQ)![无帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*BG9IQJyLHF8AAAAAAAAAAAAAARQnAQ)![反馈](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*eTWdQKCRKHwAAAAAAAAAAAAAARQnAQ)[AI](https://www.oceanbase.com/obi) 咨询热线