数据库面试基础题之执行计划

点击蓝色“有关SQL”关注我哟

加个“星标”，天天与10000人一起快乐成长

做数据库开发，执行计划是绕不开的技能之一。

很多年前，我在做C/S开发的时候，（大概很少有朋友还知道C/S模式的开发了吧）曾认为 SQL 不值一提。并集概念可以完美的解释 SQL 的所有。当我从C/S开发跳出来，往OLAP发展的时候，现实给了一记重锤。SQL 是简单，数据库却不是。

做了两年CS开发后，我决心往 OLAP 方向走一走。OLAP 是当时的“大数据”，炙手可热。4-6 倍的工资，很大程度决定了我当时的眼界。加上在集团公司一表成名，给了我相当大的鼓励。现在回想，还是太年轻。

来到上海的一家外资企业，全透明落地玻璃窗，逢人招呼就是哈罗，笑脸夸人便是奥三木。听得我像个乡下土鳖。介绍自己时，只会用 my name is L.

面试官看完我吹牛皮的调优经验，（其实就是用 SQL Server Cube, 空间换取报表查询时间），让我简要说说 execution plan。我当时就懵在那里了。什么 plan, 压根没听过。

不会就不会，一场面试而已。回头学完再来，小爷我从来只扶墙，不服输。

于是，回到家就打开微软SQL Server官方文档，找找面试官所说的 execution plan是什么鬼。中文网其实哪里有 execution plan 这个栏目，都在英文站上面。这就是会点英语的好处了。咱怎么都是大一就过6级的人，换个站点继续搜。

不搜不要紧，一搜完全是在看天书。各种花花绿绿的线，千奇百怪的图标，就算是个藏宝图，瞬间也得迷失方向。

有逻辑地址，物理地址，还有逻辑读，物理读，访问路径，更有执行算子。哎哟喂，哪有CS（一款中老年人游戏）那么有趣。于是果断放弃。

但今天我必须拿出来说说，作为三板斧之一，执行计划必学。面试过20万年薪的工程师，我也经常考察他们现场画执行计划的功底。你说为什么这么苛刻，每秒丢失的顾客下单热情，怎么能用金钱衡量？

第一个问题来了，看到下面的图，你会想到什么，是SQL写得不好，还是索引加的不对？怎么改

 

可能很多朋友对 Table Scan 不敏感，也不知道什么意思。简单介绍下，Table Scan 是从物理地址读取数据的一种算法，表上有多少数据，就读多少。没错，如果是1T的数据，也照样拉到内存里来。

1T的内存，谁家服务器这么强悍呢？懂点操作系统基本知识，就明白 Table Scan 这种算法，一定会写缓冲页，从专业角度来讲，意味着数据库等待。

怎么办？大概这是所有初级数据库开发者都会面临的第一个问题。数据库单表查询缓慢，该怎么解决？加索引呗。

好，加一个试试：

CREATE INDEX IDX_ACT_CLI_STG
    ON SalesCoverage(IS_ACTIVE) 
        INCLUDE(Client_Name,Stage)

image

再执行发现，表访问算法变了，成了 Index Seek. 并且比第一张图中的 Predicate 多了一项：Seek Predicates.

Index Seek 比起 Table Scan 好在哪里？

这个问题用专业回答解释，可以用鸿篇大著来形容。但我就说一个比喻，你秒懂。你是愿意去读800多页的 SQL Server  Internals 还是看我在这里总结的小技巧？

Index Seek 就是这样。用极简的存储，回答主要问题。

Predicate 和 Seek Predicates 那么相像，又有什么区别？

Seek Predicates 就像你翻阅公众号一样。假设数据库遇到难题了，就找【有关SQL】，点进来，搜索即可，包治百病。假设不知道【有关SQL】这么优秀的公众号，怎么办？那就采用单纯的 Predicates，翻到一个公众号，看两篇文章，若全是Java/Python, 换一个，再读两篇，还是Java/Python, 再换，直到遇到【有关SQL】公众号，L 就在这里等你，不离不弃。

看明白了吗，Seek Predicates 在规则下能有效提高查询效率，本质上，通过减少磁盘的物理寻道面积，从而减少加载的数据量。而 Predicate 仅筛选已经被提取出来的数据，并不给查询提速。

这就是执行计划基础。单表入门，多表进阶。下回继续，敬请关注！

--完--

往期精彩：

本号精华合集（二）

如何写好 5000 行的 SQL 代码

如何提高阅读 SQL 源代码的快感

我在面试数据库工程师候选人时，常问的一些题

零基础 SQL 数据库小白，从入门到精通的学习路线与书单