Cách lọc kết quả SQL trong một quan hệ có-nhiều-qua

100

Giả sử tôi có các bảng student, clubvà student_club:

student {
    id
    name
}
club {
    id
    name
}
student_club {
    student_id
    club_id
}

Tôi muốn biết cách tìm tất cả học sinh trong cả câu lạc bộ bóng đá (30) và bóng chày (50).
Mặc dù truy vấn này không hoạt động, nhưng đó là thứ gần nhất mà tôi có cho đến nay:

SELECT student.*
FROM   student
INNER  JOIN student_club sc ON student.id = sc.student_id
LEFT   JOIN club c ON c.id = sc.club_id
WHERE  c.id = 30 AND c.id = 50
mysql  sql  postgresql  sql-match-all  relational-division 
— Xeoncross
nguồn

Câu trả lời:

145

Tôi tò mò. Và như chúng ta đều biết, sự tò mò có tiếng là giết mèo.

Vậy cách lột da mèo nhanh nhất là cách nào?

Môi trường lột da mèo chính xác cho thử nghiệm này:

  • PostgreSQL 9.0 trên Debian Squeeze với RAM và cài đặt tốt.
  • 6.000 sinh viên, 24.000 thành viên câu lạc bộ (dữ liệu được sao chép từ cơ sở dữ liệu tương tự với dữ liệu đời thực.)
  • Dẫn dòng nhỏ từ sơ đồ đặt tên trong câu hỏi: student.idlà student.stud_idvà club.idlà club.club_idđây.
  • Tôi đặt tên các truy vấn theo tên tác giả của chúng trong chủ đề này, với một chỉ mục trong đó có hai.
  • Tôi đã chạy tất cả các truy vấn một vài lần để điền vào bộ nhớ cache, sau đó tôi chọn tốt nhất trong số 5 truy vấn với GIẢI THÍCH PHÂN TÍCH.

  • Các chỉ số liên quan (phải là chỉ số tối ưu - miễn là chúng ta không biết trước câu lạc bộ nào sẽ được truy vấn):

    ALTER TABLE student ADD CONSTRAINT student_pkey PRIMARY KEY(stud_id );
ALTER TABLE student_club ADD CONSTRAINT sc_pkey PRIMARY KEY(stud_id, club_id);
ALTER TABLE club       ADD CONSTRAINT club_pkey PRIMARY KEY(club_id );
CREATE INDEX sc_club_id_idx ON student_club (club_id);

    club_pkeykhông được yêu cầu bởi hầu hết các truy vấn ở đây.
    Các khóa chính tự động triển khai các chỉ mục duy nhất Trong PostgreSQL.
    Chỉ mục cuối cùng là để bù đắp cho sự thiếu sót đã biết này của các chỉ mục nhiều cột trên PostgreSQL:

Chỉ mục cây B đa cột có thể được sử dụng với các điều kiện truy vấn liên quan đến bất kỳ tập hợp con nào của các cột của chỉ mục, nhưng chỉ mục này hiệu quả nhất khi có các ràng buộc trên các cột đứng đầu (ngoài cùng bên trái).

Các kết quả:

Tổng thời gian chạy từ GIẢI THÍCH PHÂN TÍCH.

1) Martin 2: 44,594 mili giây

SELECT s.stud_id, s.name
FROM   student s
JOIN   student_club sc USING (stud_id)
WHERE  sc.club_id IN (30, 50)
GROUP  BY 1,2
HAVING COUNT(*) > 1;

2) Erwin 1: 33.217 ms

SELECT s.stud_id, s.name
FROM   student s
JOIN   (
   SELECT stud_id
   FROM   student_club
   WHERE  club_id IN (30, 50)
   GROUP  BY 1
   HAVING COUNT(*) > 1
   ) sc USING (stud_id);

3) Martin 1: 31,735 mili giây

SELECT s.stud_id, s.name
   FROM   student s
   WHERE  student_id IN (
   SELECT student_id
   FROM   student_club
   WHERE  club_id = 30
   INTERSECT
   SELECT stud_id
   FROM   student_club
   WHERE  club_id = 50);

4) Derek: 2,287 ms

SELECT s.stud_id,  s.name
FROM   student s
WHERE  s.stud_id IN (SELECT stud_id FROM student_club WHERE club_id = 30)
AND    s.stud_id IN (SELECT stud_id FROM student_club WHERE club_id = 50);

5) Erwin 2: 2,181 mili giây

SELECT s.stud_id,  s.name
FROM   student s
WHERE  EXISTS (SELECT * FROM student_club
               WHERE  stud_id = s.stud_id AND club_id = 30)
AND    EXISTS (SELECT * FROM student_club
               WHERE  stud_id = s.stud_id AND club_id = 50);

6) Sean: 2,043 ms

SELECT s.stud_id, s.name
FROM   student s
JOIN   student_club x ON s.stud_id = x.stud_id
JOIN   student_club y ON s.stud_id = y.stud_id
WHERE  x.club_id = 30
AND    y.club_id = 50;

Ba phần cuối cùng hoạt động khá giống nhau. 4) và 5) dẫn đến cùng một kế hoạch truy vấn.

Bổ sung muộn:

SQL lạ mắt, nhưng hiệu suất không thể theo kịp.

7) ypercube 1: 148,649 ms

SELECT s.stud_id,  s.name
FROM   student AS s
WHERE  NOT EXISTS (
   SELECT *
   FROM   club AS c 
   WHERE  c.club_id IN (30, 50)
   AND    NOT EXISTS (
      SELECT *
      FROM   student_club AS sc 
      WHERE  sc.stud_id = s.stud_id
      AND    sc.club_id = c.club_id  
      )
   );

8) ypercube 2: 147,497 mili giây

SELECT s.stud_id,  s.name
FROM   student AS s
WHERE  NOT EXISTS (
   SELECT *
   FROM  (
      SELECT 30 AS club_id  
      UNION  ALL
      SELECT 50
      ) AS c
   WHERE NOT EXISTS (
      SELECT *
      FROM   student_club AS sc 
      WHERE  sc.stud_id = s.stud_id
      AND    sc.club_id = c.club_id  
      )
   );

Như dự đoán, hai người đó thực hiện gần như giống nhau. Kế hoạch truy vấn dẫn đến việc quét bảng, người lập kế hoạch không tìm ra cách sử dụng các chỉ mục ở đây.

9) bộ ký tự đại diện 1: 49,849 ms

WITH RECURSIVE two AS (
   SELECT 1::int AS level
        , stud_id
   FROM   student_club sc1
   WHERE  sc1.club_id = 30
   UNION
   SELECT two.level + 1 AS level
        , sc2.stud_id
   FROM   student_club sc2
   JOIN   two USING (stud_id)
   WHERE  sc2.club_id = 50
   AND    two.level = 1
   )
SELECT s.stud_id, s.student
FROM   student s
JOIN   two USING (studid)
WHERE  two.level > 1;

SQL lạ mắt, hiệu suất tốt cho một CTE. Kế hoạch truy vấn rất kỳ lạ.
Một lần nữa, sẽ rất thú vị khi 9.1 xử lý điều này. Tôi sẽ sớm nâng cấp cụm db được sử dụng ở đây lên 9.1. Có lẽ tôi sẽ chạy lại toàn bộ shebang ...

10) bộ ký tự đại diện 2: 36,986 ms

WITH sc AS (
   SELECT stud_id
   FROM   student_club
   WHERE  club_id IN (30,50)
   GROUP  BY stud_id
   HAVING COUNT(*) > 1
   )
SELECT s.*
FROM   student s
JOIN   sc USING (stud_id);

Biến thể CTE của truy vấn 2). Đáng ngạc nhiên là nó có thể dẫn đến một kế hoạch truy vấn hơi khác với cùng một dữ liệu. Tôi đã tìm thấy một quá trình quét tuần tự trên student, trong đó biến thể truy vấn con đã sử dụng chỉ mục.

11) ypercube 3: 101,482 ms

Một bổ sung muộn khác @ypercube. Nó thực sự tuyệt vời, có bao nhiêu cách.

SELECT s.stud_id, s.student
FROM   student s
JOIN   student_club sc USING (stud_id)
WHERE  sc.club_id = 10                 -- member in 1st club ...
AND    NOT EXISTS (
   SELECT *
   FROM  (SELECT 14 AS club_id) AS c  -- can't be excluded for missing the 2nd
   WHERE  NOT EXISTS (
      SELECT *
      FROM   student_club AS d
      WHERE  d.stud_id = sc.stud_id
      AND    d.club_id = c.club_id
      )
   )

12) erwin 3: 2,377 ms

@ ypercube's 11) thực sự chỉ là phương pháp tiếp cận ngược tâm trí của biến thể đơn giản hơn này, điều đó cũng vẫn còn thiếu. Thực hiện gần như nhanh như những con mèo hàng đầu.

SELECT s.*
FROM   student s
JOIN   student_club x USING (stud_id)
WHERE  sc.club_id = 10                 -- member in 1st club ...
AND    EXISTS (                        -- ... and membership in 2nd exists
   SELECT *
   FROM   student_club AS y
   WHERE  y.stud_id = s.stud_id
   AND    y.club_id = 14
   )

13) erwin 4: 2,375 ms

Khó tin, nhưng đây là một biến thể khác, thực sự mới. Tôi thấy tiềm năng cho nhiều hơn hai tư cách thành viên, nhưng nó cũng được xếp hạng trong số những con mèo hàng đầu chỉ với hai.

SELECT s.*
FROM   student AS s
WHERE  EXISTS (
   SELECT *
   FROM   student_club AS x
   JOIN   student_club AS y USING (stud_id)
   WHERE  x.stud_id = s.stud_id
   AND    x.club_id = 14
   AND    y.club_id = 10
   )

Số lượng thành viên câu lạc bộ năng động

Nói cách khác: số lượng bộ lọc khác nhau. Câu hỏi này yêu cầu chính xác hai tư cách thành viên câu lạc bộ. Nhưng nhiều trường hợp sử dụng phải chuẩn bị cho một số lượng khác nhau.

Thảo luận chi tiết trong câu trả lời sau có liên quan này:

— Erwin Brandstetter
nguồn
1
Brandstetter, Làm việc rất tốt. Tôi đã bắt đầu một phần thưởng cho câu hỏi này để cung cấp cho bạn thêm tín dụng (nhưng tôi phải đợi 24 giờ). Dù sao, tôi tự hỏi làm thế nào những thắc mắc đi khi bạn bắt đầu thêm nhiều club_id là thay vì chỉ hai ...
— Xeoncross
@Xeoncross: Kudo cho cử chỉ hào phóng của bạn. :) Với nhiều club_ids hơn, tôi nghi ngờ rằng 1) và 2) sẽ tiến gần hơn về tốc độ, nhưng nó sẽ phải là một con số lớn hơn để lật đổ bảng xếp hạng.
— Erwin Brandstetter
nếu bạn có nhiều câu lạc bộ thì hãy tạo một bảng khác có chứa các câu lạc bộ đó. Sau đó tham gia vào bảng đó theo lựa chọn của bạn.
— Paul Morgan
@Erwin: Thnx (cho điểm chuẩn). Không phải nitpicking, nhưng có lẽ bạn có thể thử những truy vấn đó (ý tôi là tất cả, không chỉ của tôi) với một chỉ mục (student_id, club_id)(hoặc ngược lại).
— ypercubeᵀᴹ
3
Tôi có sai khi nghĩ rằng bất cứ thứ gì dưới 200 ms là hiệu suất có thể chấp nhận được, với miền được đề cập và kích thước mẫu không? Vì lợi ích cá nhân, tôi đã thực hiện các bài kiểm tra của riêng mình trên SQL Server 2008 R2 bằng cách sử dụng các chỉ mục cấu trúc giống nhau và (tôi nghĩ) trải rộng dữ liệu nhưng mở rộng đến một triệu sinh viên (một tập hợp hợp lý cho miền nhất định, tôi cảm thấy) và vẫn không có Không có gì nhiều để phân tách các cách tiếp cận khác nhau, IMO. Tất nhiên, những cái dựa trên phép phân chia quan hệ có thể nhắm mục tiêu đến một bảng cơ sở, mang lại cho chúng lợi thế về 'khả năng mở rộng'.
— onedaywhen
18 
SELECT s.*
FROM student s
INNER JOIN student_club sc_soccer ON s.id = sc_soccer.student_id
INNER JOIN student_club sc_baseball ON s.id = sc_baseball.student_id
WHERE 
 sc_baseball.club_id = 50 AND 
 sc_soccer.club_id = 30
— Sean
nguồn
10 
select *
from student
where id in (select student_id from student_club where club_id = 30)
and id in (select student_id from student_club where club_id = 50)
— Derek Kromm
nguồn
Truy vấn này hoạt động tốt, nhưng có điều gì đó làm phiền tôi về việc phải yêu cầu RDBMS kiểm tra quá nhiều chỉ mục * số lượng câu lạc bộ.
— Xeoncross
6
Tôi thích truy vấn này nhất vì giống với một phong cách sạch sẽ, giống như python trong sql. Tôi rất vui khi giao dịch 0,44ms (khác với truy vấn của Sean) cho loại mã này.
— MGP
5

Nếu bạn chỉ muốn student_id thì:

    Select student_id
      from student_club
     where club_id in ( 30, 50 )
  group by student_id
    having count( student_id ) = 2

Nếu bạn cũng cần tên từ sinh viên thì:

Select student_id, name
  from student s
 where exists( select *
                 from student_club sc
                where s.student_id = sc.student_id
                  and club_id in ( 30, 50 )
             group by sc.student_id
               having count( sc.student_id ) = 2 )

Nếu bạn có nhiều hơn hai câu lạc bộ trong một bảng club_selection thì:

Select student_id, name
  from student s
 where exists( select *
                 from student_club sc
                where s.student_id = sc.student_id
                  and exists( select * 
                                from club_selection cs
                               where sc.club_id = cs.club_id )
             group by sc.student_id
               having count( sc.student_id ) = ( select count( * )
                                                   from club_selection ) )
— Paul Morgan
nguồn
Hai câu hỏi đầu tiên được đưa vào / giống như truy vấn của tôi 1. Nhưng câu hỏi thứ ba giải quyết câu hỏi được thêm vào của @Xeoncross trong các nhận xét ở trên. Tôi sẽ bỏ phiếu cho phần đó mà không có sự lừa dối.
— Erwin Brandstetter,
Cảm ơn bạn đã nhận xét nhưng tôi cũng đang trình diễn một số định dạng. Tôi sẽ để nó 'nguyên như vậy'.
— Paul Morgan
4 
SELECT *
FROM   student
WHERE  id IN (SELECT student_id
              FROM   student_club
              WHERE  club_id = 30
              INTERSECT
              SELECT student_id
              FROM   student_club
              WHERE  club_id = 50)

Hoặc một giải pháp tổng quát hơn dễ dàng mở rộng cho ncác câu lạc bộ và tránh được INTERSECT(không có sẵn trong MySQL) và IN(vì hiệu suất của điều này kém trong MySQL )

SELECT s.id,
       s.name
FROM   student s
       join student_club sc
         ON s.id = sc.student_id
WHERE  sc.club_id IN ( 30, 50 )
GROUP  BY s.id,
          s.name
HAVING COUNT(DISTINCT sc.club_id) = 2
— Martin Smith
nguồn
Không nghi ngờ gì nữa, câu trả lời thứ hai của bạn là tốt nhất cho các truy vấn đang được tạo bằng mã. Tôi có thực sự sẽ viết 10 phép nối hoặc truy vấn con để tìm phép chia quan hệ của 10 tiêu chí không? Rất tiếc, thay vào đó, tôi sẽ sử dụng giải pháp tuyệt vời này. Cảm ơn vì đã dạy tôi những gì HAVINGlàm trong MySQL.
— Eric L.
4

CTE khác. Nó trông sạch sẽ, nhưng nó có thể sẽ tạo ra cùng một kế hoạch như một groupby trong một truy vấn con thông thường.

WITH two AS (
    SELECT student_id FROM tmp.student_club
    WHERE club_id IN (30,50)
    GROUP BY student_id
    HAVING COUNT(*) > 1
    )
SELECT st.* FROM tmp.student st
JOIN two ON (two.student_id=st.id)
    ;

Đối với những người muốn thử nghiệm, một bản sao của dữ liệu thử nghiệm tạo của tôi:

DROP SCHEMA tmp CASCADE;
CREATE SCHEMA tmp;

CREATE TABLE tmp.student
    ( id INTEGER NOT NULL PRIMARY KEY
    , sname VARCHAR
    );

CREATE TABLE tmp.club
    ( id INTEGER NOT NULL PRIMARY KEY
    , cname VARCHAR
    );

CREATE TABLE tmp.student_club
    ( student_id INTEGER NOT NULL  REFERENCES tmp.student(id)
    , club_id INTEGER NOT NULL  REFERENCES tmp.club(id)
    );

INSERT INTO tmp.student(id)
    SELECT generate_series(1,1000)
    ;

INSERT INTO tmp.club(id)
    SELECT generate_series(1,100)
    ;

INSERT INTO tmp.student_club(student_id,club_id)
    SELECT st.id  , cl.id
    FROM tmp.student st, tmp.club cl
    ;

DELETE FROM tmp.student_club
WHERE random() < 0.8
    ;

UPDATE tmp.student SET sname = 'Student#' || id::text ;
UPDATE tmp.club SET cname = 'Soccer' WHERE id = 30;
UPDATE tmp.club SET cname = 'Baseball' WHERE id = 50;

ALTER TABLE tmp.student_club
    ADD PRIMARY KEY (student_id,club_id)
    ;
— Wildplasser
nguồn
Vâng, trên thực tế đó chỉ là một truy vấn con với nhóm bằng như trong phiên bản đầu tiên của tôi. Cùng một kế hoạch truy vấn + chi phí CTE dẫn đến hiệu suất giống nhau + một chút cho CTE. Tuy nhiên, thiết lập thử nghiệm tốt.
— Erwin Brandstetter
Tôi không biết liệu có CTE-overhead hay không. Phân phối dữ liệu thử nghiệm là rất quan trọng. Tính khả dụng của số liệu thống kê: sau khi PHÂN TÍCH CHÂN KHÔNG, thời gian chạy đã tăng từ 67,4 đến 1,56 mili giây. Chỉ băm và bitmap liên quan đến QP.
— wildplasser
Điều đó đặc biệt trong trường hợp của bạn, sau khi xóa 80% một bảng lớn và cập nhật rất nhiều, bạn đã có nhiều bộ giá trị chết hơn bất cứ thứ gì khác. Không có gì lạ, phân tích chân không giúp ích rất nhiều. Tôi đã chạy cả hai biến thể có và không có CTE, và đáng ngạc nhiên là các kế hoạch truy vấn không giống nhau. hoặc tốt hơn, tôi sẽ mở một phòng trò chuyện cho điều đó.
— Erwin Brandstetter
Đừng lo lắng, tôi đã biết về 80% hàng chết ... Tôi nghĩ số liệu thống kê cũng quan trọng. Nhưng biểu đồ khá 'phẳng', được xóa ngẫu nhiên. Có thể nó chỉ là ước tính của các trang cần thiết thay đổi đủ để khiến người lập kế hoạch quyết định chuyển đổi kế hoạch.
— wildplasser
3

Vì vậy, có nhiều cách để lột da mèo .
Tôi sẽ bổ sung thêm hai cái nữa để làm cho nó hoàn thiện hơn.

1) NHÓM trước, THAM GIA sau

Giả sử một mô hình dữ liệu lành mạnh nơi (student_id, club_id)là độc đáo trong student_club. Phiên bản thứ hai của Martin Smith giống như có phần tương tự, nhưng anh ấy tham gia nhóm đầu tiên, nhóm sau đó. Điều này sẽ nhanh hơn:

SELECT s.id, s.name
  FROM student s
  JOIN (
   SELECT student_id
     FROM student_club
    WHERE club_id IN (30, 50)
    GROUP BY 1
   HAVING COUNT(*) > 1
       ) sc USING (student_id);

2) TỒN TẠI

Và tất nhiên, có cổ điển EXISTS. Tương tự như biến thể của Derek với IN. Đơn giản và nhanh chóng. (Trong MySQL, điều này sẽ nhanh hơn một chút so với biến thể với IN):

SELECT s.id, s.name
  FROM student s
 WHERE EXISTS (SELECT 1 FROM student_club
               WHERE  student_id = s.student_id AND club_id = 30)
   AND EXISTS (SELECT 1 FROM student_club
               WHERE  student_id = s.student_id AND club_id = 50);
— Erwin Brandstetter
nguồn
3

Vì chưa có ai thêm phiên bản (cổ điển) này:

SELECT s.*
FROM student AS s
WHERE NOT EXISTS
      ( SELECT *
        FROM club AS c 
        WHERE c.id IN (30, 50)
          AND NOT EXISTS
              ( SELECT *
                FROM student_club AS sc 
                WHERE sc.student_id = s.id
                  AND sc.club_id = c.id  
              )
      )

hoặc tương tự:

SELECT s.*
FROM student AS s
WHERE NOT EXISTS
      ( SELECT *
        FROM
          ( SELECT 30 AS club_id  
          UNION ALL
            SELECT 50
          ) AS c
        WHERE NOT EXISTS
              ( SELECT *
                FROM student_club AS sc 
                WHERE sc.student_id = s.id
                  AND sc.club_id = c.club_id  
              )
      )

Một lần nữa hãy thử với một cách tiếp cận hơi khác. Lấy cảm hứng từ một bài báo trong Giải thích mở rộng: Nhiều thuộc tính trong một bảng EAV: GROUP BY so với NOT EXISTS :

SELECT s.*
FROM student_club AS sc
  JOIN student AS s
    ON s.student_id = sc.student_id
WHERE sc.club_id = 50                      --- one option here
  AND NOT EXISTS
      ( SELECT *
        FROM
          ( SELECT 30 AS club_id           --- all the rest in here
                                           --- as in previous query
          ) AS c
        WHERE NOT EXISTS
              ( SELECT *
                FROM student_club AS scc 
                WHERE scc.student_id = sc.id
                  AND scc.club_id = c.club_id  
              )
      )

Cách tiếp cận khác:

SELECT s.stud_id
FROM   student s

EXCEPT

SELECT stud_id
FROM 
  ( SELECT s.stud_id, c.club_id
    FROM student s 
      CROSS JOIN (VALUES (30),(50)) c (club_id)
  EXCEPT
    SELECT stud_id, club_id
    FROM student_club
    WHERE club_id IN (30, 50)   -- optional. Not needed but may affect performance
  ) x ;
— ypercubeᵀᴹ
nguồn
+1 .. bổ sung tuyệt vời cho bộ sưu tập da mèo không quá hoàn chỉnh! :) Tôi đã thêm chúng vào điểm chuẩn.
— Erwin Brandstetter
Đó không phải là một cuộc chiến công bằng :) Lợi thế lớn của phép chia quan hệ chẳng hạn như đây là ước số có thể là một bảng cơ sở để việc thay đổi ước số rất rẻ, tức là việc cập nhật các hàng trong bảng cơ sở được nhắm mục tiêu bởi cùng một truy vấn với việc thay đổi SQL truy vấn mỗi lần.
— onedaywhen
@ErwinBrandstetter: Có thể thêm biến thể thứ 3 trong các thử nghiệm của bạn không?
— ypercubeᵀᴹ
@ypercube: Bạn hiểu rồi. Phiên bản khá xoắn. :)
— Erwin Brandstetter
1
@Erwin: Khi bạn quản lý để lãng phí thời gian vào việc này, bạn cũng có thể thử sử dụng hai Khóa DUY NHẤT, trên cả hai (stud_id, club_id)và (club_id, stud_id)(hoặc Chính và Duy nhất)? Tôi vẫn nghĩ rằng đối với một số truy vấn đó, sự khác biệt từ 2 đến 140 mili giây là quá cao để giải thích bởi sự khác biệt trong kế hoạch thực thi.
— ypercubeᵀᴹ
2 
WITH RECURSIVE two AS
    ( SELECT 1::integer AS level
    , student_id
    FROM tmp.student_club sc0
    WHERE sc0.club_id = 30
    UNION
    SELECT 1+two.level AS level
    , sc1.student_id
    FROM tmp.student_club sc1
    JOIN two ON (two.student_id = sc1.student_id)
    WHERE sc1.club_id = 50
    AND two.level=1
    )
SELECT st.* FROM tmp.student st
JOIN two ON (two.student_id=st.id)
WHERE two.level> 1

    ;

Điều này có vẻ hoạt động khá tốt, vì CTE-scan tránh được sự cần thiết của hai truy vấn con riêng biệt.

Luôn có lý do để sử dụng sai các truy vấn đệ quy!

(BTW: mysql dường như không có truy vấn đệ quy)

— Wildplasser
nguồn
+1 để tìm thêm một con đường phù hợp để đến đó! Tôi đã thêm truy vấn của bạn vào điểm chuẩn. Hy vọng điều đó là ổn với bạn. :)
— Erwin Brandstetter,
Được rồi. Nhưng tất nhiên nó được dự định như một trò đùa. CTE thực sự hoạt động tốt nếu có thêm nhiều hồ sơ câu lạc bộ sinh viên 'lạc lối' được thêm vào. (Đối với thử nghiệm tôi đã sử dụng 1000 sinh viên * 100 câu lạc bộ, và xóa 80% ngẫu nhiên)
— wildplasser
1

Các kế hoạch truy vấn khác nhau trong truy vấn 2) và 10)

Tôi đã thử nghiệm trong một db đời thực, vì vậy tên khác với danh sách da mèo. Đó là một bản sao lưu, vì vậy không có gì thay đổi trong tất cả các lần chạy thử nghiệm (ngoại trừ những thay đổi nhỏ đối với danh mục).

Truy vấn 2)

SELECT a.*
FROM   ef.adr a
JOIN (
    SELECT adr_id
    FROM   ef.adratt
    WHERE  att_id IN (10,14)
    GROUP  BY adr_id
    HAVING COUNT(*) > 1) t using (adr_id);

Merge Join  (cost=630.10..1248.78 rows=627 width=295) (actual time=13.025..34.726 rows=67 loops=1)
  Merge Cond: (a.adr_id = adratt.adr_id)
  ->  Index Scan using adr_pkey on adr a  (cost=0.00..523.39 rows=5767 width=295) (actual time=0.023..11.308 rows=5356 loops=1)
  ->  Sort  (cost=630.10..636.37 rows=627 width=4) (actual time=12.891..13.004 rows=67 loops=1)
        Sort Key: adratt.adr_id
        Sort Method:  quicksort  Memory: 28kB
        ->  HashAggregate  (cost=450.87..488.49 rows=627 width=4) (actual time=12.386..12.710 rows=67 loops=1)
              Filter: (count(*) > 1)
              ->  Bitmap Heap Scan on adratt  (cost=97.66..394.81 rows=2803 width=4) (actual time=0.245..5.958 rows=2811 loops=1)
                    Recheck Cond: (att_id = ANY ('{10,14}'::integer[]))
                    ->  Bitmap Index Scan on adratt_att_id_idx  (cost=0.00..94.86 rows=2803 width=0) (actual time=0.217..0.217 rows=2811 loops=1)
                          Index Cond: (att_id = ANY ('{10,14}'::integer[]))
Total runtime: 34.928 ms

Truy vấn 10)

WITH two AS (
    SELECT adr_id
    FROM   ef.adratt
    WHERE  att_id IN (10,14)
    GROUP  BY adr_id
    HAVING COUNT(*) > 1
    )
SELECT a.*
FROM   ef.adr a
JOIN   two using (adr_id);

Hash Join  (cost=1161.52..1261.84 rows=627 width=295) (actual time=36.188..37.269 rows=67 loops=1)
  Hash Cond: (two.adr_id = a.adr_id)
  CTE two
    ->  HashAggregate  (cost=450.87..488.49 rows=627 width=4) (actual time=13.059..13.447 rows=67 loops=1)
          Filter: (count(*) > 1)
          ->  Bitmap Heap Scan on adratt  (cost=97.66..394.81 rows=2803 width=4) (actual time=0.252..6.252 rows=2811 loops=1)
                Recheck Cond: (att_id = ANY ('{10,14}'::integer[]))
                ->  Bitmap Index Scan on adratt_att_id_idx  (cost=0.00..94.86 rows=2803 width=0) (actual time=0.226..0.226 rows=2811 loops=1)
                      Index Cond: (att_id = ANY ('{10,14}'::integer[]))
  ->  CTE Scan on two  (cost=0.00..50.16 rows=627 width=4) (actual time=13.065..13.677 rows=67 loops=1)
  ->  Hash  (cost=384.68..384.68 rows=5767 width=295) (actual time=23.097..23.097 rows=5767 loops=1)
        Buckets: 1024  Batches: 1  Memory Usage: 1153kB
        ->  Seq Scan on adr a  (cost=0.00..384.68 rows=5767 width=295) (actual time=0.005..10.955 rows=5767 loops=1)
Total runtime: 37.482 ms
— Erwin Brandstetter
nguồn
@wildplasser: Hãy xem các kế hoạch truy vấn phân kỳ! Thật bất ngờ cho tôi. trang 9.0. Phòng trò chuyện khó sử dụng, vì vậy tôi lạm dụng một câu trả lời ở đây.
— Erwin Brandstetter
Cảnh tượng kỳ lạ. Về cơ bản, QP giống nhau ở đây (9.0.1-beta-something) cho CTE: quét seq + bitmap thay vì quét chỉ mục + hợp nhất. Có thể là một lỗ hổng trong phương pháp cân bằng chi phí của người tối ưu? Tôi sẽ tạo ra thêm một sự lạm dụng CTE ...
— wildplasser
1

@ erwin-brandstetter Vui lòng đánh giá điểm này:

SELECT s.stud_id, s.name
FROM   student s, student_club x, student_club y
WHERE  x.club_id = 30
AND    s.stud_id = x.stud_id
AND    y.club_id = 50
AND    s.stud_id = y.stud_id;

Nó giống như số 6) của @sean, tôi đoán vậy.

— Taai
nguồn
2
Bạn phải biết rằng thông @báo chỉ hoạt động trong nhận xét, không có trong câu trả lời. Tôi tình cờ đọc được bài viết này. Kế hoạch truy vấn và hiệu suất truy vấn của bạn giống với truy vấn của Sean. Nó thực sự giống nhau, nhưng truy vấn của Sean với JOINcú pháp rõ ràng là dạng thường được ưa thích hơn, vì nó rõ ràng hơn. Tuy nhiên, hãy +1 cho một câu trả lời hợp lệ khác!
— Erwin Brandstetter
0 
-- EXPLAIN ANALYZE
WITH two AS (
    SELECT c0.student_id
    FROM tmp.student_club c0
    , tmp.student_club c1
    WHERE c0.student_id = c1.student_id
    AND c0.club_id = 30
    AND c1.club_id = 50
    )
SELECT st.* FROM tmp.student st
JOIN two ON (two.student_id=st.id)
    ;

Kế hoạch truy vấn:

 Hash Join  (cost=1904.76..1919.09 rows=337 width=15) (actual time=6.937..8.771 rows=324 loops=1)
   Hash Cond: (two.student_id = st.id)
   CTE two
     ->  Hash Join  (cost=849.97..1645.76 rows=337 width=4) (actual time=4.932..6.488 rows=324 loops=1)
           Hash Cond: (c1.student_id = c0.student_id)
           ->  Bitmap Heap Scan on student_club c1  (cost=32.76..796.94 rows=1614 width=4) (actual time=0.667..1.835 rows=1646 loops=1)
                 Recheck Cond: (club_id = 50)
                 ->  Bitmap Index Scan on sc_club_id_idx  (cost=0.00..32.36 rows=1614 width=0) (actual time=0.473..0.473 rows=1646 loops=1)                     
                       Index Cond: (club_id = 50)
           ->  Hash  (cost=797.00..797.00 rows=1617 width=4) (actual time=4.203..4.203 rows=1620 loops=1)
                 Buckets: 1024  Batches: 1  Memory Usage: 57kB
                 ->  Bitmap Heap Scan on student_club c0  (cost=32.79..797.00 rows=1617 width=4) (actual time=0.663..3.596 rows=1620 loops=1)                   
                       Recheck Cond: (club_id = 30)
                       ->  Bitmap Index Scan on sc_club_id_idx  (cost=0.00..32.38 rows=1617 width=0) (actual time=0.469..0.469 rows=1620 loops=1)
                             Index Cond: (club_id = 30)
   ->  CTE Scan on two  (cost=0.00..6.74 rows=337 width=4) (actual time=4.935..6.591 rows=324 loops=1)
   ->  Hash  (cost=159.00..159.00 rows=8000 width=15) (actual time=1.979..1.979 rows=8000 loops=1)
         Buckets: 1024  Batches: 1  Memory Usage: 374kB
         ->  Seq Scan on student st  (cost=0.00..159.00 rows=8000 width=15) (actual time=0.093..0.759 rows=8000 loops=1)
 Total runtime: 8.989 ms
(20 rows)

Vì vậy, nó dường như vẫn muốn quét seq trên học sinh.

— Wildplasser
nguồn
Nóng lòng xem liệu điều đó đã được sửa trong 9.1 chưa.
— Erwin Brandstetter
0 
SELECT s.stud_id, s.name
FROM   student s,
(
select x.stud_id from 
student_club x 
JOIN   student_club y ON x.stud_id = y.stud_id
WHERE  x.club_id = 30
AND    y.club_id = 50
) tmp_tbl
where tmp_tbl.stud_id = s.stud_id
;

Sử dụng biến thể nhanh nhất (Mr. Sean trong biểu đồ Brandstetter của Mr.). Có thể biến thể với chỉ một phép tham gia để chỉ ma trận student_club mới có quyền tồn tại. Vì vậy, truy vấn dài nhất sẽ chỉ có hai cột để tính toán, ý tưởng là làm cho truy vấn mỏng.

— Stepan Pavlov
nguồn
1
Mặc dù đoạn mã này có thể giải quyết câu hỏi, bao gồm một lời giải thích thực sự giúp cải thiện chất lượng bài đăng của bạn. Hãy nhớ rằng bạn đang trả lời câu hỏi cho độc giả trong tương lai, không chỉ người hỏi bây giờ! Vui lòng chỉnh sửa câu trả lời của bạn để thêm giải thích và đưa ra dấu hiệu về những hạn chế và giả định nào được áp dụng.
— BrokenBinary
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookie và Chính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.