我知道子查询在使用不正确时对性能非常不利。我有一个非常具体的场景,用户需要从表中检索一组过滤的记录。将有各种各样的过滤器可用,它们必须支持组合。此外,一组开发人员将定期创建新的过滤器。
我不喜欢一个不断增长的、具有大量参数的单一 SQL 查询的想法。我不喜欢一堆具有相同 SELECT 语句和不同 WHERE 子句的自主 SQL 查询的想法。我确实喜欢动态 SQL 查询的想法,但我不确定应该使用哪种结构。我可以想到 4 个基本选项:(如果我还缺少更多,请不要犹豫,提出建议)
- “INNER JOIN”:通过 INNER JOINS 连接过滤器以过滤结果。
- “FROM 子查询”:通过 FROM 语句中的子查询堆栈过滤器。
- “WHERE 子查询”:通过 WHERE 子句中的子查询连接过滤器。
- “INNER JOIN 子查询”:一个奇怪的混合体。
我创建了一个 SQL 小提琴来演示(和描述)它们:
以下是小提琴的摘录,以提供我在说什么的想法:
------------------------------------------------------------------------
--THIS IS AN EXCERPT FROM THE SQL FIDDLE -- IT IS NOT MEANT TO COMPILE--
------------------------------------------------------------------------
--
--"INNER JOIN" test
SELECT COUNT(*)
FROM
@TestTable Test0
INNER JOIN @TestTable Test1 ON Test1.ID=Test0.ID AND Test1.ID % @i = 0
INNER JOIN @TestTable Test2 ON Test2.ID=Test0.ID AND Test2.ID % @j = 0
INNER JOIN @TestTable Test3 ON Test3.ID=Test0.ID AND Test3.ID % @k = 0
--
--"FROM subqueries" test
SELECT COUNT(*) FROM (
SELECT * FROM (
SELECT * FROM (
SELECT * FROM @TestTable Test3 WHERE Test3.ID % @k = 0
) Test2 WHERE Test2.ID % @j = 0
) Test1 WHERE Test1.ID % @i = 0
) Test0
--
--"WHERE subqueries" test
SELECT COUNT(*)
FROM @TestTable Test0
WHERE
Test0.ID IN (SELECT ID FROM @TestTable Test1 WHERE Test1.ID % @i = 0)
AND Test0.ID IN (SELECT ID FROM @TestTable Test2 WHERE Test2.ID % @j = 0)
AND Test0.ID IN (SELECT ID FROM @TestTable Test3 WHERE Test3.ID % @k = 0)
--
--"INNER JOIN subqueries" test
SELECT COUNT(*)
FROM
TestTable Test0
INNER JOIN (SELECT ID FROM TestTable WHERE ID % @i = 0) Test1 ON Test1.ID=Test0.ID
INNER JOIN (SELECT ID FROM TestTable WHERE ID % @j = 0) Test2 ON Test2.ID=Test0.ID
INNER JOIN (SELECT ID FROM TestTable WHERE ID % @k = 0) Test3 ON Test3.ID=Test0.ID
--
--"EXISTS subqueries" test
SELECT COUNT(*)
FROM TestTable Test0
WHERE
EXISTS (SELECT 1 FROM TestTable Test1 WHERE Test1.ID = Test0.ID AND Test1.ID % @i = 0)
AND EXISTS (SELECT 1 FROM TestTable Test2 WHERE Test2.ID = Test0.ID AND Test2.ID % @j = 0)
AND EXISTS (SELECT 1 FROM TestTable Test3 WHERE Test3.ID = Test0.ID AND Test3.ID % @k = 0)
排名(执行测试的时间)
SQL小提琴:
|INNER JOIN|FROM SUBQUERIES|WHERE SUBQUERIES|INNER JOIN SUBQUERIES|EXISTS SUBQUERIES|
-------------------------------------------------------------------------------------
| 5174 | 777 | 7240 | 5478 | 7359 |
本地环境:(没有缓存:每次测试前清除缓冲区)
|INNER JOIN|FROM SUBQUERIES|WHERE SUBQUERIES|INNER JOIN SUBQUERIES|EXISTS SUBQUERIES|
-------------------------------------------------------------------------------------
| 3281 | 2851 | 2964 | 3148 | 3071 |
本地环境:(带缓存:连续运行两次查询并记录第2次运行的时间)
|INNER JOIN|FROM SUBQUERIES|WHERE SUBQUERIES|INNER JOIN SUBQUERIES|EXISTS SUBQUERIES|
-------------------------------------------------------------------------------------
| 284 | 50 | 3334 | 278 | 408 |
每种解决方案都有优点/缺点。WHERE 子句中的子查询性能非常糟糕。FROM 子句中的子查询具有相当不错的性能(实际上它们通常性能最好)(注意:我相信这种方法会否定索引的好处?)。INNER JOIN 具有相当不错的性能,尽管它引入了一些有趣的范围问题,因为与子查询不同,INNER JOIN 将在相同的上下文中运行(必须有一个中间系统来避免表别名的冲突)。
总的来说,我认为最干净的解决方案是 FROM 子句中的子查询。过滤器很容易编写和测试(因为与 INNER JOIN 不同,它们不需要提供上下文/基本查询)。
想法?这是子查询的有效用法还是等待发生的灾难?
更新(2012/10/04):
- 更新了 SQL Fiddle 以包含对“EXISTS”方法的测试
- 从 SQL Fiddle 和本地环境添加了性能测试