Мне было любопытно. И как мы все знаем, любопытство имеет репутацию убийства кошек.
Итак, какой самый быстрый способ снять кожу с кошки?
Точная среда для кошачьей шкуры для этого теста:
- PostgreSQL 9.0 в Debian Squeeze с приличной оперативной памятью и настройками.
- 6000 студентов, 24 000 членов клуба (данные скопированы из аналогичной базы данных с данными из реальной жизни).
- Небольшое отклонение от схемы именования в вопросе:
student.id - это student.stud_id, а club.id - это club.club_id здесь.
- Я назвал запросы в честь их автора в этой теме с индексом, где их два.
- Я запустил все запросы пару раз, чтобы заполнить кэш, а затем выбрал лучшее из 5 с помощью EXPLAIN ANALYZE.
Соответствующие индексы (должны быть оптимальными - до тех пор, пока нам не хватает предварительных знаний о том, какие клубы будут опрошены):
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_pkey не требуется для большинства запросов здесь.
Первичные ключи автоматически реализуют уникальные индексы в PostgreSQL.
Последний индекс должен восполнить этот известный недостаток многостолбцовых индексов в PostgreSQL:
Многоколонный индекс B-дерева можно использовать с условиями запроса, которые
задействовать любое подмножество столбцов индекса, но индекс наиболее
эффективен, когда есть ограничения на ведущую (крайнюю слева)
столбцы.
Результаты:
Общее время выполнения из EXPLAIN ANALYZE.
1) Мартин 2: 44,594 мс
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) Эрвин 1: 33,217 мс
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) Мартин 1: 31,735 мс
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) Дерек: 2,287 мс
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) Эрвин 2: 2,181 мс
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) Шон: 2,043 мс
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;
Последние три работают почти одинаково. 4) и 5) приводят к одному и тому же плану запросов.
Поздние добавления:
Необычный SQL, но производительность не справляется.
7) ypercube 1: 148,649 мс
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 мс
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
)
);
Как и ожидалось, эти двое работают почти одинаково. План запроса приводит к сканированию таблицы, планировщик не находит здесь способа использовать индексы.
9) wildplasser 1: 49,849 мс
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, достойная производительность для CTE. Очень экзотический план запроса.
Опять же, было бы интересно, как 9.1 справляется с этим. Я собираюсь обновить кластер БД, используемый здесь, до 9.1 в ближайшее время. Может быть, я перезапущу весь Шебанг ...
10) wildplasser 2: 36,986 мс
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);
CTE вариант запроса 2). Удивительно, но это может привести к несколько другому плану запросов с точно такими же данными. Я нашел последовательное сканирование в student, где вариант подзапроса использовал индекс.
11) ypercube 3: 101,482 мс
Еще одно позднее добавление @ypercube. Удивительно, сколько существует способов.
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) Эрвин 3: 2,377 мс
@ ypercube's 11) на самом деле является просто извращающим обратным подходом этого более простого варианта, который также все еще отсутствовал. Выступает почти так же быстро, как и лучшие кошки.
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) Эрвин 4: 2,375 мс
Трудно поверить, но вот еще один, действительно новый вариант. Я вижу потенциал для более чем двух членов, но он также входит в число лучших кошек с двумя.
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
)
Динамическое количество членов клуба
Другими словами: различное количество фильтров. Этот вопрос задал ровно два членства в клубах. Но во многих случаях нужно готовиться к изменению числа.
Подробное обсуждение в следующем ответе: