En termes d'efficacité de l'index, l'index conjoint est nettement plus efficace. Dans de nombreux cas, si vous utilisez plusieurs champs pour interroger, vous devriez envisager d'utiliser l'index conjoint.
Mais les choses ne sont pas complètement absolues, et les frais généraux d'indexation doivent également être pris en compte.
En prenant vos conditions comme exemple, en supposant que key peut déterminer de manière unique un enregistrement, n'est-il pas nécessaire d'ajouter parentId ?
Prendre du recul, même si key ne peut pas en déterminer un de manière unique, s'il peut déterminer le résultat défini dans une certaine petite plage, comme 5 enregistrements ou 10 enregistrements, alors parentId cette condition n'est rien de plus que celles-ci 10 enregistrements Analysez à nouveau l'enregistrement pour trouver l'enregistrement approprié. Par rapport à la surcharge d'écriture, de stockage et de mémoire causée par son ajout à l'index, je peux choisir de ne pas le mettre du tout dans l'index commun.
Plus une condition peut filtrer d'enregistrements, meilleure est sa « sélectivité ». De manière générale, lorsque nous construisons un indice, nous devons placer les conditions avec une meilleure sélectivité au premier plan et les conditions avec une mauvaise sélectivité à la fin. Si c'est déjà assez grave, ne le laissez pas entrer.
Il s’agit en fait d’un équilibre entre le temps et l’espace. Les conditions placées dans l'index permettent de gagner du temps (y compris le temps CPU, le temps de requête) et de l'espace (y compris l'espace de stockage, l'espace mémoire). Les conditions ne sont pas mises dans l'index, mais économisent de l'espace. La plupart du temps, nous attendons le premier. Le choix du second dépend de votre propre évaluation de la situation réelle.