Requêtes SQL - Comment lent est trop lent?

Question

Avez-vous des normes formelles ou informelles pour une vitesse de requête SQL raisonnablement atteignable? Comment les appliquez-vous? Supposons une base de données OLTP de production sous pleine charge de production réaliste d'une douzaine de requêtes par seconde, correctement équipées et configurées.

exemple personnel à titre d'exemple (et non une recommandation, très subordonnées à de nombreux facteurs, dont certains hors de votre contrôle):

Attente:

Chaque unité transactionnelle (déclaration unique, plusieurs instructions SQL du début à la fin les limites de transaction, ou une seule procédure stockée, la plus grande des deux) doit s'exécuter en moyenne en une seconde ou moins, sans valeurs aberrantes anormales.

Résolution:

requêtes Plus lent doivent être optimisés à la norme. Les requêtes lentes pour les rapports et autres analyses sont déplacées vers un cube OLAP (meilleur cas) ou une base de données d'instantanés statiques.

(Il est évident que certaines requêtes d'exécution (Insertion/mise à jour/Supprimer) ne peut pas être déplacé, doit donc être optimisé, mais jusqu'à présent, dans mon expérience, il a été possible.)

Answer 1

J'utilise généralement la règle de la seconde pour écrire/refactoriser des procédures stockées, bien que mon lieu de travail ne dispose pas de règles spécifiques à ce sujet. C'est juste mon bon sens. L'expérience me dit que s'il faut dix secondes ou plus pour qu'une procédure s'exécute, ce qui n'effectue pas de gros insertions en masse, il y a généralement de sérieux problèmes dans le code qui peuvent facilement être corrigés.

Ils sont le problème le plus commun que je rencontre dans SP: s avec des performances médiocres est l'utilisation incorrecte des index, provoquant des opérations de recherche d'index coûteux.

Answer 2

Étant donné que vous ne pouvez pas attendre déterministe performances sur un système qui pourrait (au moins en théorie) être soumis à des pics de charge transitoires, vous voulez que votre performance SLA soit probabiliste. Un exemple de ceci pourrait être:

95% des transactions à compléter dans les 2 secondes.
95% des requêtes de recherche (plus approprié pour un écran de recherche) pour terminer dans les 10 secondes.
95% des rapports d'exploitation doivent être complétés dans les 10 secondes.

Les requêtes transactionnelles et de recherche ne peuvent pas être déplacées du système transactionnel. Les seules actions que vous pouvez effectuer sont l'optimisation de la base de données ou de l'application ou l'achat de matériel plus rapide.

Pour les rapports opérationnels, vous devez être impitoyable sur ce qui peut être considéré comme un rapport opérationnel. Seuls les rapports que absolument doivent avoir accès à des données à jour doivent être exécutés sur le système en direct. Les rapports qui font beaucoup d'E/S sont très anti-sociaux sur un système de production, et les schémas normalisés ont tendance à être assez inefficaces pour les rapports. Déplacez tous les rapports qui ne nécessitent pas de données en temps réel vers un entrepôt de données ou vers un autre établissement de rapports distinct.

Answer 3

O de N est bon et pire que N^2 sera finalement trop lent.