Astuces dans Sql Server

Question

Des astuces sont-elles vraiment nécessaires pour chaque instruction SQL? Nous avons un DBA qui est anal à ce sujet et nous demande de mettre des astuces sur chaque instruction select et update dans nos procs stockés. Est-ce vraiment nécessaire?

Answer 1

Pas habituellement. Les mettre sur tout semble exagéré.

La documentation indique

Etant donné que l'optimiseur de requêtes SQL Server sélectionne généralement le meilleur plan d'exécution pour une requête, nous vous recommandons d'utiliser join_hint, query_hint et table_hint uniquement en dernier recours par des développeurs et des administrateurs de base de données expérimentés

Answer 2

Votre DBA a tort .

De MS :

  

Parce que l'optimiseur de requêtes SQL Server   sélectionne généralement la meilleure exécution   planifier pour une requête, nous recommandons que    indicateur de jointure , indicateur de requête et    indice de table être utilisé uniquement comme dernier   recours par des développeurs expérimentés et   administrateurs de bases de données.

Answer 3

Les indices ne sont que des indices. Ils aident l’optimiseur à faire le meilleur travail possible. Mais comme pour toute optimisation, vous devriez vous concentrer sur les déclarations qui sont en réalité des problèmes.

Answer 4

Dépend - l’optimiseur de requêtes fait de très bons choix d’intention. Quelles sont les astuces de votre DBA? @Ned est un petit problème - un conseil indique explicitement à l'optimiseur de ne pas trouver de chemin - mais utilisez plutôt votre optimisation.

Légiférer selon lequel vous devriez toujours ou jamais utiliser des indices, c'est un peu ignorer les problèmes que ces indices sont à résoudre. Quelques occasions où des allusions ont été critiques:

• NOLOCK pour supprimer explicitement les verrous de lecture des tables de recherche de domaine interrogées dans une transaction.
• cliqueter un plan de requête sur un index spécifique à cause des statistiques " dérive " pendant les mises à jour lourdes (dans ce cas, le plan est passé à l'analyse de table sur une table de rangée de 10 m que d'utiliser l'index clusterisé)

Vous n'avez jamais eu à utiliser d'indications de jointure.

Answer 5

Normalement, c'est juste à l'envers. Toutefois, selon votre situation, cela pourrait être souhaitable.

Par exemple, nous avons une base de données (un ensemble de bases de données sur un serveur, en réalité) où les données sont toutes des captures instantanées nocturnes d’un système mainframe, utilisées à des fins de rapport et autres. À part le traitement par lots qui recrée les bases de données chaque nuit, rien n'écrit dans ce système. Dans ce contexte, le schéma de verrouillage par défaut n’est pas approprié et la politique entre notre groupe et le groupe informatique qui gère tous nos serveurs nous empêche de le modifier. Donc, à peu près toutes les requêtes sur ces dbs ont les astuces avec (nolock) .

J'imagine qu'il existe d'autres situations dans lesquelles vous pouvez avoir des bases de données de génération de rapports sans écriture, ou peut-être l'inverse: une base de données d'archivage ou de journalisation rarement lue. Le fait est qu’il peut arriver qu’une base de données spécialisée soit configurée lorsque le schéma de verrouillage par défaut ne convient pas et que vous ne pouvez pas le modifier. Ensuite, vous aurez besoin d'une pléthore de pinatas ... Je veux dire des allusions.

Mais c'est l'exception qui confirme la règle. En général, l’optimiseur de base de données est plus intelligent que vous en ce qui concerne le verrouillage, par exemple.