---
title: 添加列后，查询语句包含新加列时默认计划不优-OceanBase数据库使用指南
description: 了解OceanBase数据库在实际应用中关于添加列后，查询语句包含新加列时默认计划不优相关的常见问题和使用技巧，帮助您快速解决添加列后，查询语句包含新加列时默认计划不优的难题。
image: https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*OSPzQ6GUQF4AAAAAQHAAAAgAeiGDAQ/original
---
切换语言

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

划线反馈

# 添加列后，查询语句包含新加列时默认计划不优

更新时间：2026-08-21 03:56

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

## 摘要

当表中新增列且未完成基线数据重写时，若查询语句包含了新加列，优化器可能因无法感知存储层实际变化而错误低估全表扫描的代价，从而选择代价较低但实际执行效果不佳的计划。此时，需要对表执行全量合并以使执行计划符合预期。

## 问题现象

在表新增一列后，执行包含该列的查询语句时，优化器选择了全表扫描计划，但实际执行时间远高于预期。

例如，执行以下查询：

```sql
SELECT * FROM t1 WHERE workdate = '20251123';

```

优化器估算的全表扫描代价（est.time）低于索引扫描代价，因此默认选择了全表扫描计划。然而，实际执行该计划扫描了 639 万行数据，耗时 23.8 秒，性能远低于预期。

**注意**：此问题并非优化器选错了基表计划，而是其选择的计划实际执行时间过高，不符合预期。

进一步查询对应 Trace 的 SQL Audit 可以发现，大量的数据访问需要扫描磁盘，无法利用存储层的下压优化。

## 问题原因

在 OceanBase 数据库中，当表结构发生变化（特别是新增列）后，在完成基线数据重写之前，优化器无法感知存储层的实际变化，可能会错误地低估全表扫描的代价。

由于新列加入后，在基线数据重写完成前，优化器仍按照旧的数据分布情况来评估执行计划的成本，未能考虑到新列带来的数据访问模式变化，导致代价估算存在偏差，进而影响了执行计划的选择。

## 解决方案

对表执行全量合并后，优化器能够正确选择索引扫描，查询性能可恢复至预期水平。

## 适用版本

- 3.x
 - 4.2.x
 - 4.3.x

## 补充信息

当前 4.3.5.1 版本已修复此问题，但尚未回溯至较低版本。

对于受影响的版本，建议采取以下方式作为临时解决方案：

- 对表执行全量合并。
 - 通过 SQL Plan Management（SPM）绑定索引计划。

以避免因代价估算不准导致的查询性能问题。

上一篇

[大量 union all 与 not in 条件 SQL 语句执行报错 4013](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000006897662)

下一篇

[PL 常见问题](https://www.oceanbase.com/knowledge-base/oceanbase-database-20000001051) ![有帮助](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) 咨询热线