Oui si vous:
- exécutez SQL Server 2014 ou version ultérieure; et
- sont capables d'exécuter la requête avec l' indicateur de trace 176 actif; et
- la colonne calculée est
PERSISTED
Plus précisément, au moins les versions suivantes sont requises :
- Mise à jour cumulative 2 pour SQL Server 2016 SP1
- Mise à jour cumulative 4 pour SQL Server 2016 RTM
- Mise à jour cumulative 6 pour SQL Server 2014 SP2
MAIS pour éviter un bug (ref pour 2014 , et pour 2016 et 2017 ) introduit dans ces correctifs, appliquez plutôt:
L'indicateur de trace est efficace en tant –T
qu'option de démarrage , à la fois à l'échelle globale et à la portée de la session DBCC TRACEON
, et par requête avec OPTION (QUERYTRACEON)
ou un guide de plan.
L'indicateur de trace 176 empêche l'expansion persistante de la colonne calculée.
La charge de métadonnées initiale effectuée lors de la compilation d'une requête apporte toutes les colonnes, pas seulement celles directement référencées. Cela rend toutes les définitions de colonnes calculées disponibles pour la correspondance, ce qui est généralement une bonne chose.
Comme effet secondaire malheureux, si l'une des colonnes chargées (calculées) utilise une fonction scalaire définie par l'utilisateur, sa présence désactive le parallélisme pour la requête entière, même lorsque la colonne calculée n'est pas réellement utilisée .
L'indicateur de trace 176 aide à cela, si la colonne est persistante, en ne chargeant pas la définition (car l'expansion est ignorée). De cette façon, une fonction scalaire définie par l'utilisateur n'est jamais présente dans l'arbre de requête de compilation, donc le parallélisme n'est pas désactivé.
Le principal inconvénient de l'indicateur de trace 176 (en plus d'être seulement légèrement documenté) est qu'il empêche également la correspondance d'expression de requête avec des colonnes calculées persistantes: si la requête contient une expression correspondant à une colonne calculée persistante, l'indicateur de trace 176 empêchera l'expression d'être remplacée par une référence à la colonne calculée.
Pour plus de détails, consultez mon article SQLPerformance.com, Colonnes calculées correctement persistantes .
Étant donné que la question mentionne XML, comme alternative à la promotion de valeurs à l'aide d'une colonne calculée et d'une fonction scalaire, vous pouvez également envisager d'utiliser un index XML sélectif, comme vous l'avez écrit dans les index XML sélectifs: pas mal du tout .