Mysql
 sql >> Base de données >  >> RDS >> Mysql

Comment filtrer les résultats SQL dans une relation has-many-through

J'étais curieux. Et comme nous le savons tous, la curiosité a la réputation de tuer les chats.

Alors, quel est le moyen le plus rapide d'écorcher un chat ?

L'environnement de peau de chat pour ce test :

  • PostgreSQL 9.0 sur Debian Squeeze avec une RAM et des paramètres corrects.
  • 6 000 étudiants, 24 000 adhésions à des clubs (données copiées à partir d'une base de données similaire avec des données réelles.)
  • Léger détournement du schéma de nommage dans la question :student.id est student.stud_id et club.id est club.club_id ici.
  • J'ai nommé les requêtes d'après leur auteur dans ce fil de discussion.
  • J'ai exécuté toutes les requêtes plusieurs fois pour remplir le cache, puis j'ai choisi la meilleure des 5 avec EXPLAIN ANALYZE .
  • Indices pertinents (devraient être l'optimum - tant que nous ne savons pas à l'avance quels clubs seront interrogés) :
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 n'est pas requis par la plupart des requêtes ici.
Les clés primaires implémentent automatiquement des index uniques dans PostgreSQL.
Le dernier index est pour compenser cette lacune connue de index multi-colonnes sur PostgreSQL :

Un index B-tree multicolonne peut être utilisé avec des conditions de requête impliquant n'importe quel sous-ensemble des colonnes de l'index, mais l'index est plus efficace lorsqu'il existe des contraintes sur les colonnes de tête (les plus à gauche).

Résultats

Nombre total d'exécutions depuis EXPLAIN ANALYZE .

1) Martin 2 :44,594 ms

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 ms

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 ms

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;

Les trois derniers font à peu près la même chose. 4) et 5) aboutissent au même plan de requête.

Ajouts tardifs

SQL fantaisiste, mais les performances ne peuvent pas suivre :

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 ms

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  
      )
   );

Comme prévu, ces deux-là fonctionnent presque de la même manière. Les résultats du plan de requête dans les analyses de table, le planificateur ne trouve pas le moyen d'utiliser les index ici.

9) wildplasser 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;

Fantaisie SQL, performances décentes pour un CTE. Plan de requête très exotique.

10) wildplasser 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);

Variante CTE de la requête 2). Étonnamment, cela peut entraîner un plan de requête légèrement différent avec exactement les mêmes données. J'ai trouvé un scan séquentiel sur student , où la variante de sous-requête utilisait l'index.

11) ypercube 3 :101,482 ms

Un autre ypercube d'ajout tardif. C'est vraiment incroyable, combien de façons il y a.

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) n'est en fait que l'approche inverse de cette variante plus simple, qui manquait toujours. Fonctionne presque aussi vite que les meilleurs félins.

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

Difficile à croire, mais voici une autre variante véritablement nouvelle. Je vois un potentiel pour plus de deux adhésions, mais il se classe également parmi les meilleurs chats avec seulement deux.

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
   );

Nombre dynamique d'adhésions au club

En d'autres termes :nombre variable de filtres. Cette question demandait exactement deux adhésions à des clubs. Mais de nombreux cas d'utilisation doivent se préparer à un nombre variable. Voir :