J'essaie de comprendre comment l'échantillonnage des statistiques fonctionne et si le comportement escompté ci-dessous est attendu sur les mises à jour des statistiques échantillonnées.
Nous avons une grande table partitionnée par date avec quelques milliards de lignes. La date de partition est la date commerciale antérieure et est donc une clé ascendante. Nous chargeons uniquement les données de ce tableau pour la veille.
Le chargement des données s'exécute pendant la nuit, donc le vendredi 8 avril, nous avons chargé les données pour le 7.
Après chaque exécution, nous mettons à jour les statistiques, bien que nous prenions un échantillon plutôt qu'un FULLSCAN.
Peut-être que je suis naïf, mais je m'attendais à ce que SQL Server identifie la clé la plus élevée et la clé la plus basse de la plage pour garantir l'obtention d'un échantillon de plage précis. Selon cet article :
Pour le premier compartiment, la limite inférieure est la plus petite valeur de la colonne sur laquelle l'histogramme est généré.
Cependant, il ne mentionne pas le dernier compartiment / la plus grande valeur.
Avec la mise à jour des statistiques échantillonnées le matin du 8, l'échantillon a raté la valeur la plus élevée du tableau (le 7).
Comme nous effectuons beaucoup de requêtes sur les données de la veille, cela a entraîné une estimation de cardinalité inexacte et un certain nombre de requêtes expirant.
SQL Server ne doit-il pas identifier la valeur la plus élevée pour cette clé et l'utiliser comme maximum RANGE_HI_KEY? Ou est-ce juste une des limites de la mise à jour sans utilisation FULLSCAN?
Version SQL Server 2012 SP2-CU7. Nous ne pouvons pas actuellement mettre à niveau en raison d'un changement de OPENQUERYcomportement dans SP3 qui arrondissait les nombres dans une requête de serveur lié entre SQL Server et Oracle.