Question

我是SQL的新手，我有一个问题。

我有这个SQL代码：

DROP TABLE if exists students;
DROP TABLE if exists grades;

CREATE TABLE students(
    s_id integer NOT NULL PRIMARY KEY,
    s_name text,
    s_last_name text,
    curr_year integer
);

CREATE TABLE grades(
    s_id integer NOT NULL PRIMARY KEY,
    course text,
    c_year integer,
    grade integer,
    FOREIGN KEY (s_id) REFERENCES students
);

INSERT INTO students (s_id, s_name, s_last_name, curr_year)
VALUES (1, 'A', 'S', 3);

INSERT INTO students (s_id, s_name, s_last_name, curr_year)
VALUES (2, 'A', 'A', 2);

INSERT INTO students (s_id, s_name, s_last_name, curr_year)
VALUES (3, 'V', 'B', 1);

INSERT INTO students (s_id, s_name, s_last_name, curr_year)
VALUES (4, 'K', 'N', 2);

INSERT INTO grades (s_id, course, c_year, grade)
VALUES (1, 'DB', 2, 98);

INSERT INTO grades (s_id, course, c_year, grade)
VALUES (2, 'OS', 3, 90);

INSERT INTO grades (s_id, course, c_year, grade)
VALUES (3, 'DB', 2, 94);

EXPLAIN ANALYZE
    SELECT * 
    FROM students s JOIN grades gr
    ON s.s_id = gr.s_id
    WHERE curr_year > 0;



CREATE INDEX student_details ON students(s_id, s_name, s_last_name);
CREATE INDEX student_courses ON grades(s_id, course);

EXPLAIN ANALYZE
    SELECT * 
    FROM students s JOIN grades gr
    ON s.s_id = gr.s_id
    WHERE curr_year > 0;


DROP INDEX student_details;
DROP INDEX student_courses;
DROP TABLE students CASCADE;
DROP TABLE grades CASCADE;

我试着理解解释输出。在INDEX创建之前，我得到了哈希合并。这是解释输出：

 Hash Join  (cost=23.50..51.74 rows=270 width=116) (actual time=0.039..0.050 rows=3 loops=1)
   Hash Cond: (gr.s_id = s.s_id)
   ->  Seq Scan on grades gr  (cost=0.00..21.30 rows=1130 width=44) (actual time=0.005..0.008 rows=3 loops=1)
   ->  Hash  (cost=20.12..20.12 rows=270 width=72) (actual time=0.021..0.021 rows=4 loops=1)
         Buckets: 1024  Batches: 1  Memory Usage: 9kB
         ->  Seq Scan on students s  (cost=0.00..20.12 rows=270 width=72) (actual time=0.006..0.011 rows=4 loops=1)
               Filter: (curr_year > 0)
 Planning time: 0.147 ms
 Execution time: 0.089 ms
(9 rows)

在INDEX创建之后，我得到了嵌套循环：

Nested Loop  (cost=0.00..2.12 rows=1 width=116) (actual time=0.031..0.116 rows=3 loops=1)
   Join Filter: (s.s_id = gr.s_id)
   Rows Removed by Join Filter: 9
   ->  Seq Scan on students s  (cost=0.00..1.05 rows=1 width=72) (actual time=0.012..0.018 rows=4 loops=1)
         Filter: (curr_year > 0)
   ->  Seq Scan on grades gr  (cost=0.00..1.03 rows=3 width=44) (actual time=0.003..0.009 rows=3 loops=4)
 Planning time: 0.396 ms
 Execution time: 0.170 ms

但我无法弄清楚为什么？为什么我的案例中的索引使得嵌套循环优于Hash Join？我很乐意为此得到解释。

非常感谢！

Answer 1

Glib回答：因为查询规划器认为它更快。

最佳猜测：当您拥有索引时，查询计划程序可以使用从索引中读取数据的顺序来执行嵌套循环而不进行排序，比哈希更快。如果没有索引，它会进行排序，并且sort + loop的组合比hash更慢。

Answer 2

“嵌套循环”连接有点用词不当。从技术上讲，它指的是嵌套循环 - 顾名思义：

for every row in table1
    for every row in table2
        compare values and execute join

在实践中，这通常用作：

for every row in table1
    for every matching row in table2
        execute join

差别很小，但“匹配”意味着嵌套循环连接可以使用索引。因此，嵌套循环连接可能具有非常差的性能（如果表相对较大且没有索引），或者它可以具有非常好的性能（如果它可以使用索引）。

Answer 3

似乎没有人回答这个问题。这两个执行计划都不使用索引，因此为什么在创建索引时计划程序会从使用HJ更改为使用NL。我的猜测是，在创建索引之后，可以使用比以前更好的表和列统计信息。我不知道创建索引是否会导致填充表统计信息，或者计划者是否正在使用索引的统计信息来选择路径。追踪计划者并找出答案会很有趣。我是Oracle的人，可以在那做。我不知道该如何在PostgreSQL上进行这种分析。

例如，如果您查看

上的顺序扫描

学生 HJ行估计为1130 NL行估计为1 实际行是4

等级 HJ行估计为270 NL行估计为3 实际行是3

NL统计信息更准确，因此创建索引后，统计信息发生了一些变化。快速测试是删除索引并查看计划程序的工作。如果仍然使用相同的统计数据执行NL，则必须更改表中的统计数据。如果要根据HJ估算值返回HJ，则必须是索引的统计信息。

变得怪异。因此，我删除了索引，它继续使用NL。很好，很有道理。创建索引必须具有更新的表统计信息。因此，我删除表，重新创建，然后分析表，而不是创建索引。猜猜是什么，它使用HJ 但是...统计数据是准确的，就像NL一样。更多问题... 猜测创建索引必须进行一些统计分析，而不仅仅是运行分析。

散列连接与嵌套循环

3 个答案: