Comme vous ne contrôlez pas l'algorithme sélectionné, il n'y a aucun moyen de le savoir directement. Cependant, sans index, un SELECT doit être O(n) (une analyse de table doit inspecter chaque enregistrement, ce qui signifie qu'elle sera mise à l'échelle avec la taille de la table).
Avec un index, un SELECT est probablement O(log(n)) (bien que cela dépende de l'algorithme utilisé pour l'indexation et des propriétés des données elles-mêmes si cela est vrai pour n'importe quelle table réelle). Pour déterminer vos résultats pour n'importe quelle table ou requête, vous devez recourir au profilage des données du monde réel pour être sûr.
INSERT sans index devrait être très rapide (proche de O(1)) tandis que UPDATE doit d'abord trouver les enregistrements et sera donc plus lent (légèrement) que le SELECT qui vous y amène.
INSERT avec des index sera probablement à nouveau dans le stade de O(log(n^2)) lorsque l'arbre d'index doit être rééquilibré, plus proche de O(log(n)) sinon. Le même ralentissement se produira avec un UPDATE s'il affecte les lignes indexées, en plus des coûts SELECT.
Tous les paris sont ouverts une fois que vous parlez de JOIN dans le mix :vous devrez profiler et utiliser les outils d'estimation des requêtes de vos bases de données pour obtenir une lecture à ce sujet. Notez également que si cette requête est critique pour les performances, vous devez re profil de temps en temps, car les algorithmes utilisés par votre optimiseur de requête changeront à mesure que la charge de données change.
Une autre chose à garder à l'esprit... big-O ne vous parle pas des coûts fixes pour chaque transaction. Pour les tables plus petites, ceux-ci sont probablement plus élevés que les coûts de travail réels. Par exemple :les coûts de configuration, de démontage et de communication d'une requête inter-réseaux pour une seule ligne seront certainement supérieurs à la recherche d'un enregistrement indexé dans une petite table.
Pour cette raison, j'ai découvert que le fait de pouvoir regrouper un groupe de requêtes associées dans un seul lot peut avoir un impact beaucoup plus important sur les performances que toute optimisation que j'ai apportée à la base de données proprement dite.
