Bonsoir,
Pour ta première question:
Si tu fais souvent des requêtes sur les champs X et Y ensemble, alors oui, c’est certainement intéressant de créer un index pour le couple, mais en même temps ça dépend des requêtes exactes que tu fais.
Pour t’assurer que l’index est bien utilisé, sers-toi de la commande explain / describe (après avoir créé l’index). La sortie t’indique si l’index est effectivement utilisé ou non pour cette requête.
Par contre, si tu as déjà un index sur X et Y, alors il est totalement inutile de créer un index sur X uniquement.
Plus généralement, ça ne sert à rien de créer un index qui est le préfixe d’un autre.
En effet, l’index sur X,Y peut aussi parfaitement être utilisé quand tu fais une requête sur X uniquement.
Attention par contre, des index sur Y seul ou sur Y,X peuvent avoir leur utilité pour d’autres requêtes, complètement indépendamment de l’index sur X,Y.
Attention aussi au fait qu’un index sur X,Y ne pourra pas être utilisé pour une requête portant sur Y mais pas sur X.
Pour ta deuxième question:
Il faut garder à l’esprit que ton index sur slug ne sert absolument à rien dans la requête qui liste les pages, sauf si
- Dans le select, tu ne demandes que des champs qui se trouvent dans ce seul et même index
- Ou si l’index est trié et si tu tries les résultats dans le même ordre
Dans le premier cas, le moteur peut aller lire toutes les données dont il a besoin juste en lisant l’index. C’est très avantageux, tu remplaces un scan de la table par un scan de l’index qui est forcément plus petit et donc plus rapide.
Dans le deuxième cas, pour une requête paginée, tu permets au moteur de commencer la lecture de la table à un point précis plutôt qu’au début à chaque fois. En moyenne sur toutes les exécutions de cette requête, tu ne scan ainsi que la moitié de la table plutôt que la table entière.
Ceci dit ça reste à vérifier, je ne suis même pas sûr que MySQL/MariaDB utilise effectivement cette possibilité.
Dans tous les autres cas, un scan complet de la table sera de toute manière nécessaire, l’index est totalement inutile.
Il ne faut pas oublier qu’un index sert à indiquer où aller chercher des données dans la table, pour ne pas avoir à la lire en entier.
Donc si ta requête n’a pas de condition sur une donnée indexée, l’index ne sert à rien.
Petite aparetée: tu n’as pas de condition sur slug, mais tu as la condition status=1 dans ta requête par contre, donc on pourrait se demander si un index sur status serait utile.
Je suppose que la grande majorité de tes pages sont publiées. Du coup l’index qui t’indiquerait que tu dois aller presque tout lire ne servirait pas à grand chose.
On appelle ça la sélectivité. Plus elle est petite, ou, dit autrement, plus la condition a le pouvoir d’éliminer des cas, plus l’index est intéressant.
Note que c’est directement lié aux différentes valeurs possibles pour le champ et à leur fréquence d’apparition. Si on admet que status ne peut prendre que la valeur 1 (publié) ou 0 (non publié), au mieux la sélectivité ne pourra être que de 50%.
C’est pas hyper sélectif, donc pas très intéressant.
Pour le cas de la requête simple qui récupère une page précise, la réflexion est en fait un peu dans le même genre.
Inclure status dans l’index peut permettre de faire un court-circuit rapide, i.e. éviter d’aller lire les autres données dans la table si on voit directement dans l’index que rien ne correspond à ce qu’on cherche.
Ca ne me parait pas très utile, dans le sens où on s’attend à ce que, dans l’écrasante majorité des exécutions de la requête, la page demandée existe et est bien publiée. Ca pourrait éventuellement faire une différence significative si on s’attendait majoritairement plutôt à l’inverse, et encore, je n’y crois pas trop.
Là pour moi la balance entre l’avantage potentiel déjà très discutable que ça peut apporter, et l’ajout d’une donnée supplémentaire dans l’index est vite faite: d’après moi ça ne vaut clairement pas la peine.
