Je suis en train de conserver des procédures stockées pour SQL Server 2005 et j'aimerais pouvoir utiliser une nouvelle fonctionnalité en 2008 qui permet à l'indice de requête: "Optimiser l'inconnu"
Il semble que la requête suivante (écrit pour SQL Server 2005) estime le même nombre de lignes (c.-à-d. Sélectivité) comme si l'option (optimiser pour inconnu) a été spécifiée: Cette requête évite les paramètres reniflant en déclarant et en définissant une nouvelle variable . Est-ce vraiment un serveur SQL Server 2005 pour la fonctionnalité optimisée-for-fornd? Ou je manque quelque chose? (Les liens autoritatifs, les réponses ou les résultats des tests sont appréciés). Plus d'infos:
Un test rapide sur SQL Server 2008 me dit que le nombre de lignes estimées dans cette requête est en fait la même chose que si optimiser l'inconnu a été spécifié. Est-ce le même comportement sur SQL Server 2005? Je pense que je me souviens d'avoir entendu une fois que sans plus d'informations, le moteur d'optimisation du serveur SQL doit deviner la sélectivité du paramètre (généralement à 10% pour les prédicats d'inégalité). Je cherche toujours des informations définitives sur le comportement SQL 2005 cependant. Je ne suis pas tout à fait sûr que des informations existent si ... Plus d'info 2:
Pour être claire, cette question demande une comparaison de l'indice de requête inconnu et de la technique de masquage des paramètres que je décris. C'est une question technique, pas une question de résolution de problèmes. J'ai envisagé de nombreuses autres options et j'ai réglé à ce sujet. Donc, le seul objectif de cette question était de m'aider à gagner une certaine confiance que les deux méthodes sont équivalentes.
4 Réponses :
question intéressante.
Il y a un bon article sur la programmation SQL et le blog de l'équipe de développement de l'API ICI qui répertorie les solutions de contournement, pré-SQL 2008 comme:
Ce qui me conduit sur Cet article , qui mentionne votre Contournement de l'utilisation de paramètres locaux et de la manière dont il génère un plan d'exécution basé sur des statistiques. Dans quelle mesure ce processus est similaire pour le nouvel optimiseur pour un indice inconnu, je ne sais pas. Mon hunch est c'est une solution de contournement raisonnable.
J'ai le même hunch. Et votre "je ne sais pas" est la question que je demande ... Mais merci d'avoir pris le temps de répondre.
J'ai utilisé cette solution plusieurs fois récemment pour éviter le paramètre reniflant sur SQL 2005 et il me semble faire la même chose que d'optimiser pour inconnu sur SQL 2008. Son résolu beaucoup de problèmes que nous avons eu avec une partie de notre plus grand procédures stockées parfois suspendues lorsqu'elles ont passé certains paramètres.
C'est encourageant. Cela semble être la même chose pour moi aussi. Je me demande s'il y a un moyen de savoir à coup sûr.
D'accord, alors j'ai fait des expériences. Je vais écrire les résultats ici, mais je veux d'abord dire que sur la base de ce que j'ai vu et je sais, je suis convaincu que Utiliser des paramètres temporaires en 2005 et 2008 est exactement équivalent à l'utilisation de l'optimisation de 2008 pour inconnue . Au moins dans le contexte des procédures stockées. Voici ce que j'ai trouvé.
Dans la procédure ci-dessus, j'utilise la base de données AventureWorks. (Mais j'utilise des méthodes similaires et obtiennent des résultats similaires pour toute autre base de données) J'ai couru: et je vois des statistiques avec 200 étapes de son histogramme. En regardant son histogramme, je vois qu'il y a 66 rangées de plage distinctes (c'est-à-dire 66 valeurs distinctes qui n'étaient pas incluses dans les statistiques comme valeurs d'égalité). Ajoutez les 200 lignes d'égalité (à partir de chaque étape), et je reçois une estimation de 266 valeurs distinctes pour la productide dans des ventes.SalesorderOserdetail. avec 121317 rangées dans la table, je peux estimer que chaque productible a 456 rangées en moyenne. Et quand je regarde le plan de requête pour ma procédure de test (au format XML), je vois quelque chose comme: donc je sais que la valeur des estimes provient de (précision de Trois décimales) et remarquez que l'attribut paramètreCompiledValue est manquant dans le plan de requête. C'est exactement ce qu'un plan ressemble à l'utilisation de l'optimisation de 2008 pour inconnue
J'utilise cette technique de masquage des paramètres pendant au moins l'année écoulée car des problèmes de performance impairs, et cela a bien fonctionné, mais est très gênant de faire tout le temps.
J'ai aussi utilise Je n'ai pas de tests contrôlés car je ne peux pas éteindre sélectivement l'utilisation de chaque activation automatiquement dans le système, mais je soupçonne que le masquage du paramètre ne fera qu'aider si le paramètre est utilisé. . J'ai des SP complexes où le paramètre n'est pas utilisé dans chaque relevé, et je m'attends à ce que avec recompilement .
avec recompilement était toujours nécessaire car certaines des tables de travail "temporaires" ne sont pas remplies (ou même indexées de manière identique, si J'essaie d'accorder) de la même manière à chaque exécution, et certaines déclarations ultérieures ne s'appuient pas sur le paramètre une fois que les tables de travail sont déjà suffisamment peuplées. J'ai cassé des processus dans de multiples SPS précisément pour que le travail effectué pour remplir une table de travail dans un SP puisse être correctement analysé et exécuté contre avec recompilement dans le prochain sp.
Adathediv a suggéré d'utiliser l'indice recompilé. J'ai décidé contre cela à cause de ma situation particulière (volume élevé, grand Sprat, etc.). Mais merci pour la technique, c'est bon de savoir. Je vais le mettre dans ma boîte à outils mental.
Découvrez Kimberly Tripp's Articl SQLSKILLS.COM/BLOGS/KIMBERLY/POST/PROCSPSPANDNR.ASPX et recherchez "exactement la même chose que d'optimiser pour inconnu". Je suis prêt à lui faire confiance :-)