Il y a longtemps, j'avais l'habitude de publier des résumés de Connect - de petits articles qui mettaient en évidence quelques rapports de bugs ou des suggestions sur Connect qui, selon moi, méritaient plus d'attention. Maintenant, je dirai ceci :je ne suis pas vraiment un grand fan d'un système où la personne qui a le plus d'amis prêts à voter obtient ce qu'elle veut, car l'équipe SQL Server devrait pouvoir ignorer ou différer le bruit, et se concentrer sur les bugs ou suggestions les plus importants et les plus impactants. Mais ce n'est pas comme ça qu'ils font à Redmond . Alors, aujourd'hui, j'ai une demande :aidez-moi en votant et en commentant ces trois éléments Connect, qui visent tous à améliorer le fonctionnement des statistiques SQL Server.
(Notez que les commentaires ont beaucoup plus de poids que le simple nombre de votes, veuillez donc indiquer votre analyse de rentabilisation, si vous en avez une qui peut être partagée.)
Indice MAXDOP pour UPDATE STATISTICS
SQL Server 2016 a ajouté un indice MAXDOP pour les commandes DBCC CHECK, alors pourquoi pas pour les mises à jour des statistiques ? Sur les tables partitionnées, cela peut avoir un impact important sur le reste de la charge de travail. Nous devrions également pouvoir remplacer le MAXDOP défini par le système pour les mises à jour automatiques des statistiques, mais pour l'instant, je serais satisfait d'avoir plus de contrôle sur la gestion manuelle des statistiques. La demande est capturée dans l'élément Connect suivant :
- Connect #628971 :Ajouter le paramètre MAXDOP aux statistiques de mise à jour
Laisser l'optimiseur de requête voir les statistiques au niveau de la partition
Erin Stellato a blogué sur les avantages des statistiques incrémentielles ici, mais a vraiment mis le doigt sur ses problèmes dans cet article :les statistiques incrémentielles ne sont PAS utilisées par l'optimiseur de requête. Veuillez lire cela, puis voter et commenter l'élément que je viens de créer (je n'arrive pas à croire que je n'ai jamais remarqué qu'un DCR n'existait pas déjà pour cela) :
- Connect #2010834 :Optimizer devrait en fait *utiliser* les statistiques par partition
Les statistiques automatiques doivent tenir compte du nombre de lignes dans un index/statistique filtré
Actuellement, s'appuyer sur les mises à jour automatiques des index filtrés et des statistiques revient à attendre Godot - l'algorithme utilise le nombre de lignes dans la table pour déterminer le seuil de désabonnement, et non le nombre de lignes dans l'index. Cela signifie que la plupart des index filtrés - et en fait les plus utiles index filtrés – ne seront jamais mis à jour automatiquement. (J'en parle ici, et Kimberly Tripp en parle ici et ici. Je suis sûr que d'autres ont également blogué à ce sujet.) Je pense qu'il est temps que cela change - si vous êtes d'accord, veuillez voter et commenter l'article de Joe Sack (le titre indique des statistiques filtrées, mais il se rapporte vraiment aux deux) :
- Connect #509638 :Suggestion de modification des mises à jour des statistiques filtrées
