---
title: "SQL 优化体系 - OceanBase 数据库 V4.3.4 | OceanBase 文档中心"
description: SQL 优化体系 SQL 是用户使用数据库的常用方式，我们可以通过 SQL 实现数据的定义、存储、更新、查询等所有数据的管理操作。它是一种高度非过程化的编程语言，用户只需要提出“干什么”，无须具体指明“怎么干”，不要求用户指定对数据的存放方法，也不需要用户了解具体的数据存放方式。SQL 更像是一种偏“口语化”的编程语…
---
切换语言

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

文档反馈![](https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*P8CuR4UJ_FkAAAAAAAAAAAAADiGDAQ/original) OceanBase 数据库分布式版 - V 4.3.4

# SQL 优化体系

更新时间：2024-12-06 23:00:00

[编辑](https://github.com/oceanbase/oceanbase-doc/edit/V4.3.4/zh-CN/600.manage/900.performance-tuning/400.sql-tuning/100.sql-tuning-overview.md)  

SQL 是用户使用数据库的常用方式，我们可以通过 SQL 实现数据的定义、存储、更新、查询等所有数据的管理操作。它是一种高度非过程化的编程语言，用户只需要提出“干什么”，无须具体指明“怎么干”，不要求用户指定对数据的存放方法，也不需要用户了解具体的数据存放方式。SQL 更像是一种偏“口语化”的编程语言，就和我们平时说话一样，有主谓宾的层次结构。举个例子，我们去图书馆借书，跟图书管理员说“我要一本中国近代史”，SQL 语句就是 `select * from book where book_name='中国近代史'`。图书管理员需要提前对所有图书进行分类和排序，比如我们在“中国近代史”这本书入库的时候，就将它放到“文史类区域、近现代史书架、第二层第三本”，等想要拿书的时候就非常方便了。反之，如果图书入库的时候只是随便堆放，在书本少的时候或许还能应付，否则将是大海捞针一样效率极低。 “分类、排序”的管理方法就是数据库 SCHEMA 的索引结构，高效合理的索引设计对于 SQL 性能来说至关重要。我们常说的 SQL 优化，最核心的就是怎么减少 SQL 执行时扫描的数据量，即是 SQL 索引优化。我们日常在使用 SQL 的过程中，需要考虑 SQL 优化的场景会比优化单一 SQL 复杂很多，比如：

- 针对现有的索引，怎么写 SQL 性能会更好？
 - 针对一条 SQL，创建什么样的索引性能会更好？
 - 针对一个业务系统，怎么设计合理的索引能达到最佳性能？
 - 针对一个数据库，出现异常怎么找出有问题的 SQL 并快速恢复？

本章节，主要从研发阶段、集成阶段、运维阶段各个环节介绍 SQL 优化体系的建设。

## 研发阶段：写好 SQL

在日常研发过程中，对于写好 SQL，最重要的就是做好三件事：

1. 设定 SQL 研发规范，并严格按照规范执行。
 2. 根据业务场景合理规划 Schema，让 SQL 走上高效的索引。
 3. 针对单一 SQL，思考可优化场景。

SQL 研发规范是 SQL 质量保障的基础，是帮助 SQL 变得更加稳定的重要手段。在 SQL 运行阶段发现的 SQL 问题，可能已经对业务造成影响，且常用的 SQL 应急没法覆盖所有的 SQL 问题，比较被动。所以，制定明确的 SQL 研发规范，可以将 SQL 问题的节点前移至研发阶段，解决代码中出现低级 SQL 错误、规避潜在 SQL 隐患。

Schema 设计是随着业务场景的不断变化，而持续进行设计和优化的过程。一个复杂的业务系统，会包含各种各样的 SQL，各种 SQL 的负载结构会随着业务模型的变化而变化，底层业务数据的持续写入也会引起数据分布的不断变化。我们要不断根据 SQL 负载情况来优化 Schema 设计，让 SQL 能持续保持和业务吞吐的一种最佳实践。毕竟，我们不是为了保证每一条 SQL 的性能最佳，这不必要也很难做到，因为这可能会花费更高的成本。

针对单一 SQL，最关键的是让 SQL 能走上合理的索引，减少数据扫描行数是最有效的调优手段。此外，我们还需要从业务的角度去思考，该 SQL 实现的业务需求，是否还有更加合理的方式。同时，我们还需要预测 SQL 上线后，会不会随着数据变化，SQL 存在性能拐点或者潜在风险。

当我们在研发阶段写好了 SQL，已经最大程度上保障了 SQL 的稳定性，在源头上减少了烂 SQL 的产生。

## 集成阶段：风险阻断

在集成阶段提交 SQL 到正式运行环境，最重要就一件事情：SQL Review。就像代码写完做测试，到提交前的 Code Review 一样，SQL Review 是研发环节里必不可少的。那么，我们做 SQL Review 主要关注哪些呢？

1. 检查 SQL 研发规范
 2. 评估 SQL 性能

检测 SQL 研发规范，是需要扫描 SQL 是否符合研发规范，有助于研发规范的落地。SQL 研发规范的实施，不仅可以减少低级 SQL 错误，防止一些低性能 SQL 场景的发生，也可以增加 SQL 的可读性，便于 SQL 业务场景理解，辅助人为 SQL 问题排查。

SQL 性能评估，需要提前识别很多 SQL 风险隐患，主要关注是否能走上高效的索引、是否需要 Rewrite 优化、是否会出现性能下降等。在审核时如果需要数据支持或者了解业务场景，可以在对实现方式做进一步评审。

当我们在集成阶段 Review 到了 SQL 隐患，可以有效阻断风险 SQL 上线，在过程中削减了烂 SQL 的产生。

## 运维阶段：见招拆招

运维阶段进行的 SQL 优化，一般是我们处理最多的情况。因为 SQL 刚上线之初，数据量小、并发低，很多 SQL 不会出现性能问题。随着业务量的增长和数据的积累，SQL 可能会越来越慢，或者执行计划突然变化导致的性能骤降。运维阶段，我们需要做的 SQL 优化包含如下几件事：

- 异常诊断，找出有问题的 SQL
 - 根因分析，确认引起 DB 突然 crash 的 SQL
 - SQL 应急，对根因 SQL 进行应急来恢复 DB
 - 日常治理，持续对 DB 中的烂 SQL 进行治理
 - 持续优化，归档异常案例，举一反三

异常检测和根因分析需要了解常见的 SQL 问题，积累并沉淀 SQL 异常排查经验，帮助快速确定到根因问题，以便可以进行应急并回复业务。我们将分享常见的 SQL 典型场景和案例。

SQL 应急大致可以分为两个方式：执行计划干预和 SQL 限流。如果在 SQL 有正确的执行计划或者有合适的索引，可以通过 OceanBase 的 outline 来绑定计划或索引，进行执行计划干预，可以快速有效恢复。如果需要增加索引才能恢复，时效就会很久，需要待索引创建成功后才能达到干预效果。如果 SQL 不是计划选择的问题，往往多是 SQL 容量相关的问题，有效的方式就是进行 SQL 限流。但是 SQL 限流对于业务是有损的，需要牺牲 SQL 的并发来恢复整体 DB。

日常治理和持续优化，则需要我们在数据库运维过程中，持续推进数据库上的低性能 SQL 的优化，来降低因为烂 SQL 数据库 crash 的风险。

 上一篇 下一篇 ![有帮助](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) 咨询热线