Cela revient essentiellement à savoir si 10 index de taille N sont plus efficaces qu'un index de taille N * 10. Si vous regardez uniquement les lectures, les index séparés devraient toujours être plus rapides. Les promenades b-tree associées examineront un jeu de clés plus petit, etc.
Il y a cependant quelques points à considérer :
- Les index sur les champs de tableau indexent essentiellement chaque élément de tableau séparément. En tant que tel, la surcharge de recherche sera au maximum de 1 à 2 étapes supplémentaires pendant la marche de l'arbre b, ce qui représente un impact négligeable sur les performances. En d'autres termes, ils seront presque aussi rapides.
- Avoir 10 index peut signifier que chaque mise à jour/insertion nécessitera la mise à jour de plus d'un index (selon que vos index partagent un champ ou si vous mettez à jour plus d'un horodatage à la fois). Il s'agit d'une considération importante en termes de performances.
- L'utilisation d'un index de tableau facilite un peu l'ajout d'horodatages supplémentaires (par exemple, Timestamp10).
- Il y a une limite au nombre d'espaces de noms que vous pouvez utiliser par base de données (24k) et chaque index en occupe un. Si vous créez un index séparé par champ, cela peut devenir un problème.
- Plus important encore, l'index de tableau est beaucoup plus simple et simplifiera votre code et donc la maintenabilité. Étant donné les différences de performances limitées, je dirais que c'est la motivation la plus forte pour opter pour un index de tableau ici.
