从 SQL Server 的角度回答这个问题,因为这已发布在 SQL Server 部分。
获得第 N 份薪水的方法有很多,我们可以将这些方法分为两个部分,一种是使用 ANSI SQL 方法,另一种是使用 TSQL 方法。您还可以查看这个发现 nth highest salary youtube video,它实际上显示了一些东西。让我们尝试介绍三种编写此 SQL 的方式。
- 方法 1:- ANSI SQL:- 使用 Simple order by 和 top 关键字。
- 方法 2:- ANSI SQL:- 使用共同相关的子查询。
- 方法 3:- TSQL:- 使用 Fetch Next
方法 1:- 使用简单的 order by 和 top。
在这种方法中,我们将结合使用 order by 和 top 关键字。我们可以将我们的思考过程分为 4 个步骤:-
第 1 步:- 降序:- 我们首先使用 order by 子句使其降序。
第二步:- 然后使用TOP关键字,选择TOP N。其中N代表你想要的最高薪级。
第 3 步:- 升序:- 使数据升序。
第 4 步:- 选择前 1 个。这样就完成了。
所以,如果您在 SQL 中记下上述 4 个逻辑步骤,就会出现如下所示的内容。
下面是 SQL 的文本,以防你想执行和测试它。
select top 1 * from (select top 2 EmployeeSalary from tblEmployee
order by EmployeeSalary desc) as innerquery order by EmployeeSalary
升序
方法一的参数化问题
方法 1 的最大问题之一是“参数化”。
如果您想将上述 SQL 包装到一个存储过程中,并输入您想要的最高薪水作为参数,则方法 1 会很困难。
您可以使用方法 1 做的一件事是使其成为动态 SQL,但这不是一个优雅的解决方案。让我们看看方法 2,它是一种 ANSI SQL 方法。
方法 2:- 使用共同相关的子查询。
以下是相关子查询解决方案的外观。如果您不熟悉 Co-related 子查询。关联子查询是查询内查询的查询。外部查询首先评估,将记录发送到内部查询,内部查询然后评估并将其发送到外部查询。
查询中的“3”是我们要找出的最高薪水。
从 tblEmployee 中选择 E1.EmployeeSalary 作为 E1 其中 3=(Select
count(*) from tblEmployee as E2 where
E2.EmployeeSalary>=E1.EmployeeSalary)
所以在上面的查询中我们有一个外部查询:-
从 tblEmployee 中选择 E1.EmployeeSalary 作为 E1
内部查询位于 where 子句中。注意那些指示外部表别名如何在 where 子句中引用的粗体,这使得相互关联的内部和外部查询来回评估:-
where 3=(Select count(*) from tblEmployee as E2 Where
E2.EmployeeSalary>=E1.EmployeeSalary)
现在假设您有 3000、4000、1000 和 100 之类的记录,以下是步骤:-
- 前 3000 个将被发送到内部查询。
- 内部查询现在将检查有多少记录值大于或等于 3000。如果记录数不相等,它将采用下一个值,即 4000。现在对于 3000,只有 2 个值更大大于或等于 3000 和 4000。那么,数字记录计数是否 2>-=3? .NO,所以它需要第二个值,即 4000。
- 再次对 4000 有多少记录值大于或等于。如果记录数不相等,则取下一个值,即 1000。
- 现在 1000 有 3 条记录大于或等于 1000,(3000,4000 和 1000 自己)。这是 co-related 停止和退出并给出最终输出的地方。
方法 3:- TSQL 提取和下一步。
第三种方法是使用 TSQL。通过使用 Fetch 和 Next,我们可以轻松获得第 N 高。
但请注意,TSQL 代码不适用于其他数据库,我们需要重新重写整个代码。
这将是一个三步过程:-
第 1 步 Distinct and Order by descending: - 首先应用 distinct 和 order by 使薪水下降以及清除重复项。
第 2 步使用偏移量: - 使用 TSQL 偏移量并获取前 N-1 行。其中 N 是我们想要得到的最高薪水。偏移量采用指定的行数,保留其他行。为什么是 (N-1),因为它从零开始。
第 3 步使用 Fetch: - 使用 fetch 并获取第一行。那一行的薪水最高。
SQL 看起来如下所示。
性能比较
下面是性能比较的SQL计划。
以下是 top 和 order by 的计划。
以下是相关查询的计划。您可以看到运营商的数量非常多。所以肯定 co-related 对海量数据表现不佳。
下面是比cor-related更好的TSQL查询计划。
因此,总结起来,我们可以更全面地进行比较,如下表所示。