我们在学习 SQL 时，常常会看到这样的论调：SQL 是一种描述性语言，你只需要告诉它要做什么，而不需要告诉它怎么做，它会自己找到实现方法。也就是说，你要只用它描述任务目标，而不需要说明计算过程，这和传统的过程式语言有本质的差别。

真是这样的吗？

试一个例子，我们用 SQL 来查询员工中销售部女员工的数量，写出来是这样：

SELECT COUNT(*) FROM 员工表 WHERE 部门 =‘销售’ AND 性别 =‘女’

看起来是这样，我们不需要关心具体的计算过程（遍历员工表中每一条记录，碰到符合条件的则计数加 1，不符合条件者略过，最后看计数），只要说清要查询的目标就可以了。

再举一例，按部门统计 30 岁以上员工的平均工资：

SELECT 部门,AVERAGE(工资) FROM 员工表 WHERE 年龄 >30 GROUP BY 部门

也不错，在这里我们确实不必关心到底如何分组和计算平均。

尽管 SQL 仍然是一种严格语法，我们经过一定的学习才能写出正确的语句，但如果能不关心计算过程，那还是会省很多事的。

我们再看一个例子：找出销售额贡献度在前一半的大客户。如果设计一下计算过程，那么很容易想到这样的流程：

1. 计算所有客户的总销售额，记为 S

2. 把客户按销售倒排序，即大的在前小的在后

3. 按 2 的列表从 0 开始累加客户的销售额，超过 S/2 时停止，则已经遍历过后客户则是目标客户

那么，用 SQL 写出来是什么样的呢？

SELECT 客户, 销售额, 销售额累计

FROM (SELECT 客户, 销售额,SUM( 销售额) OVER (ORDER BY 销售额 DESC) 销售额累计 FROM 订单统计表 )

WHERE 销售额累计 < (SELECT SUM( 销售额) FROM 订单统计表 )/2

仔细看一下这个 SQL（我没想出更简单的写法了），它几乎是在严格地描述上述过程，所不同的只是书写次序（SQL 把开始计算总销售额写在了后面），和微小的逻辑差异（要把所有的累计销售额计算出来，再找出前面的）。

计算逻辑也是类似的：有个子句计算总销售额，再有个子句按销售额倒排序，利用窗口函数计算出排序后列表的每一行的累计销售额，最上层再过滤出累计销售额小于总销售额一半的客户。

这个计算逻辑比开始描述的过程还复杂些，SQL 的有序和分步运算不好，要把所有累计额都算出来，也就是说比我们开始设计的步骤还要复杂些。而这句 SQL 也是很严格地描述了这样的一个过程。

说好的只要描述任务目标而不必关心计算过程呢？

再看简单一些的例子：查询销售额贡献最多的 10 名客户。

某些 SQL 写出来是这样：

SELECT TOP 10 客户 FROM 订单统计表 ORDER BY 销售额 DESC

如果用某著名数据库来做，还得用子查询：

SELECT 客户

FROM (SELECT rownumber rn, 客户 FROM 订单统计表 ORDER BY 销售额 DESC)

WHERE rn<=10

这两个 SQL 都明白无误地告诉我们计算过程：按销售额倒排序之后取前面 10 个。

如果再找个数百行的 SQL（存储过程）来看，则可以更清楚地看到 SQL 照样在解释计算过程，而且不同的计算过程还会带来截然不同的计算性能甚至计算结果。

其实。任何程序设计语言都可以说在某种程度下的描述性语言：只需要关心目标而不必关心过程。如用 Java 写程序，你只要关心变量如何变化，而不必关心 CPU 中寄存器的动作，但用汇编语言就要关心；同样，而用汇编语言时，虽然你要关心寄存器的取值，但却不必关心 CPU 里与非门是如何动作的；用 SQL 写代码时一般不用再关心变量、循环的具体动作，但要操心表、字段这些概念上的计算过程。SQL 和其它程序设计语言在描述问题的解决方法上只是抽象层次不同，对于过程的说明并没有任何本质的不同。前面那两个例子之所以让我们感觉 SQL 象是所谓描述性语言，只是因为情况非常简单，恰好只是 SQL 抽象层次内的基本运算。而 SQL 因为长得又很象英语，在简单情况时易读易写，更容易给人这种错觉。

SQL 是非常成功的程序语言，但说它是一种与众不同的描述性语言，却是一句鬼话。拿一些简单问题举例，能蒙住暂时没有深入思考的人。其实，只要把问题稍复杂化一点，这个说法就会露馅。可惜，很多人都不会去做哪怕一点点地深入求证，而只人云亦云。SQL 并不比其它语言有更多的“描述性”和更少“过程性”，当然这并不减少 SQL 的成功程度。