后浪云带你简单聊聊OceanBase里SQL调优那些事儿，流程也不复杂

（引用来源：后浪云技术分享）

今天咱们就轻松一点,聊聊在OceanBase数据库里，怎么给SQL语句做调优，这事儿听起来好像很高深，又是“调优”又是“性能”的，但其实把思路理清楚了，流程一点也不复杂，就跟医生看病差不多，讲究个“望闻问切”。

咱得知道为啥要调优,简单说，就是某条SQL语句跑得太慢了，或者消耗了太多的资源（比如CPU、内存），拖慢了整个系统的后腿，你的感觉可能就是，一个查询以前秒出结果，现在要转半天圈圈，这时候，你就得考虑给它“看看病”了。

那第一步是啥呢？发现病灶”，也就是找到那条有问题的SQL，OceanBase提供了很多现成的工具来帮你做这个事，比如一些系统视图或者运维管理平台。（引用来源：OceanBase官方文档关于性能视图的介绍）你可以直接在这些地方看到哪些SQL执行时间长、执行次数多、或者消耗的CPU高，把它们从一大堆正在运行的SQL里揪出来，这是调优的开始。

找到目标SQL之后,第二步就是“诊断病因”了，光知道它慢不行，咱得知道它为啥慢，这里就要请出一个超级重要的工具——执行计划。（引用来源：OceanBase SQL调优核心概念）你可以理解为，这是数据库自己制定的一个“作战方案”，它详细描述了为了得到你的查询结果，数据库打算先做什么、后做什么，比如先扫描哪个表，用哪个索引，怎么把两个表的数据合并起来等等。

怎么看这个执行计划呢？很简单，在SQL语句前面加上EXPLAIN这个关键字再执行，OceanBase就不会真的去查数据，而是把它的“作战方案”打印给你看，对于这个执行计划，我们重点要看什么呢？主要看有没有一些“危险信号”。

1. 全表扫描：这个就像你在一个没有按字母顺序排列的电话本里找一个人，得从头翻到尾，效率最低，执行计划里如果看到对某个大表的“TABLE SCAN”，那就要警惕了。
2. 复杂的连接操作：如果两个非常大的表要以一种低效的方式连接在一起，也会非常耗时。
3. 排序操作：如果查询要求排序（比如ORDER BY），而数据量又很大，这个排序过程也会很慢。

通过看执行计划,你大概就能猜到，慢是因为没走索引，还是表连接方式不对，或者是别的什么原因。

病因诊断清楚了,第三步就是“开药方”了，也就是想办法优化，常用的“药”有这么几种：

• 创建或修改索引：这是最立竿见影的方法之一。（引用来源：常见的SQL优化手段）如果发现慢是因为全表扫描，那就要想想，能不能为查询条件里的字段加个索引，比如你经常按“用户名”查用户信息，那在“用户名”字段上建个索引，速度可能一下子就上来了，但是索引也不是越多越好，因为它会影响数据插入和更新的速度，所以得权衡。
• 改写SQL语句：换一种写法，数据库就能生成一个更好的执行计划。（引用来源：SQL编写最佳实践）避免在查询条件里对字段做计算或者用函数，像WHERE YEAR(create_time) = 2023，就可能用不上create_time索引，改成WHERE create_time >= '2023-01-01' AND create_time < '2024-01-01'效果会更好，还有，尽量避免使用SELECT *，只查询需要的字段，也能减少数据传输和处理的负担。
• 调整统计信息：数据库优化器制定执行计划时，依赖于它对表数据量、数据分布等情况的认识，这个认识就是“统计信息”。（引用来源：OceanBase优化器工作原理）如果统计信息过时了，优化器可能会制定一个很傻的计划，这时候，手动更新一下统计信息（比如运行ANALYZE TABLE命令），可能什么都不用改，SQL速度就恢复正常了。

最后一步,也是很重要的一步，观察疗效”，你做了优化之后，比如加了索引或者改了SQL，一定要再次执行一下，看看速度是不是真的变快了，最好能再次查看执行计划，确认优化器现在选择的路径是不是你期望的那样，如果效果不好，那就得回过头来再分析，是不是诊断有误，或者“药方”开得不对。

OceanBase的SQL调优流程其实就是一个循环：发现问题SQL -> 查看执行计划诊断原因 -> 采取优化措施（加索引/改SQL/更新统计信息等） -> 验证优化效果，它不像一门玄学，而更像一个有理有据的排查过程，只要你敢于动手去用EXPLAIN这个工具，多观察、多尝试，慢慢就能找到感觉，解决大部分的SQL性能问题，调优的目标就是用最小的代价，最快地拿到想要的数据。