La quantité d'indexation et la ligne d'en faire trop dépendront de nombreux facteurs. Sur les petites tables comme votre table "catégories", vous ne voulez ou n'avez généralement pas besoin d'un index et cela peut en fait nuire aux performances. La raison en est qu'il faut des E/S (c'est-à-dire du temps) pour lire un index, puis plus d'E/S et de temps pour récupérer les enregistrements associés aux lignes correspondantes. Une exception étant lorsque vous n'interrogez que les colonnes contenues dans l'index.
Dans votre exemple, vous récupérez toutes les colonnes et avec seulement 22 lignes et il peut être plus rapide de simplement faire une analyse de table et de les trier au lieu d'utiliser l'index. L'optimiseur peut/devrait faire cela et ignorer l'index. Si tel est le cas, l'index prend simplement de la place sans aucun avantage. Si votre table "catégories" est souvent consultée, vous pouvez envisager de l'épingler en mémoire afin que le serveur de base de données la garde accessible sans avoir à accéder au disque tout le temps.
Lors de l'ajout d'index, vous devez équilibrer l'espace disque, les performances des requêtes et les performances de mise à jour et d'insertion dans les tables. Vous pouvez vous en tirer avec plus d'index sur des tables statiques et qui ne changent pas beaucoup, contrairement aux tables avec des millions de mises à jour par jour. Vous commencerez à ressentir les effets de la maintenance de l'index à ce moment-là. Ce qui est acceptable dans votre environnement est et ne peut être déterminé que par vous et votre organisation.
Lorsque vous effectuez votre analyse, assurez-vous de générer/mettre à jour vos statistiques de table et d'index afin d'être assuré d'obtenir des calculs précis.
