Votre plan d'exécution
En regardant le plan de requête, nous pouvons voir qu'un index est touché pour servir deux opérations de filtrage.
En termes très simples, en raison de l'opérateur TOP, un objectif de ligne a été fixé. De plus amples informations et conditions préalables sur les objectifs de rang peuvent être trouvées ici
De cette même source:
Une stratégie d'objectif de ligne signifie généralement privilégier les opérations de navigation non bloquantes (par exemple, les jointures de boucles imbriquées, les recherches d'index et les recherches) par rapport aux opérations de blocage basées sur des ensembles comme le tri et le hachage. Cela peut être utile chaque fois que le client peut bénéficier d'un démarrage rapide et d'un flux régulier de lignes (avec peut-être un temps d'exécution global plus long - voir le post de Rob Farley ci-dessus). Il y a aussi les utilisations les plus évidentes et traditionnelles, par exemple pour présenter les résultats une page à la fois.
La table entière est sondée dans les filtres à l'aide d'une semi-jointure gauche qui a un objectif de ligne défini, dans l'espoir de renvoyer les 5 lignes aussi rapidement et efficacement que possible.
Cela ne se produit pas, ce qui entraîne de nombreuses itérations sur le .Fulltextmatch TVF.
Recréer
Sur la base de votre plan , j'ai pu recréer quelque peu votre problème:
CREATE TABLE dbo.Person(id int not null,lastname varchar(max));
CREATE UNIQUE INDEX ui_id ON dbo.Person(id)
CREATE FULLTEXT CATALOG ft AS DEFAULT;
CREATE FULLTEXT INDEX ON dbo.Person(lastname)
KEY INDEX ui_id
WITH STOPLIST = SYSTEM;
GO
INSERT INTO dbo.Person(id,lastname)
SELECT top(12000) ROW_NUMBER() OVER (ORDER BY (SELECT NULL)),
REPLICATE(CAST('A' as nvarchar(max)),80000)+ CAST(ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) as varchar(10))
FROM master..spt_values spt1
CROSS APPLY master..spt_values spt2;
CREATE CLUSTERED INDEX cx_Id on dbo.Person(id);
Exécution de la requête
SELECT TOP (5) *
FROM dbo.Person
WHERE "id" = 1 OR contains("lastName", '"B*"');
Résultats dans un plan de requête comparable au vôtre:
Dans l'exemple ci-dessus, B n'existe pas dans l'index de texte intégral. En conséquence, cela dépend du paramètre et des données de l'efficacité du plan de requête.
Une meilleure explication de cela peut être trouvée dans Row Goals, Part 2: Semi Joins par Paul White
... En d'autres termes, à chaque itération d'une application, nous pouvons arrêter de regarder l'entrée B dès que la première correspondance est trouvée, en utilisant le prédicat de jointure poussé. C'est exactement le genre de chose pour laquelle un objectif de ligne est bon: générer une partie d'un plan optimisé pour renvoyer rapidement les n premières lignes correspondantes (où n = 1 ici).
Par exemple, changer le prédicat pour que les résultats soient trouvés bien plus tôt (au début de l'analyse).
select top (5) *
from dbo.Person
where "id" = 124
or contains("lastName", '"A*"');
le where "id" = 124est éliminé en raison du prédicat d'index de texte intégral renvoyant déjà 5 lignes, satisfaisant le TOP()prédicat.
Les résultats le montrent également
id lastname
1 'AAA...'
2 'AAA...'
3 'AAA...'
4 'AAA...'
5 'AAA...'
Et les exécutions de TVF:
Insertion de nouvelles lignes
INSERT INTO dbo.Person
SELECT 12001, REPLICATE(CAST('B' as nvarchar(max)),80000);
INSERT INTO dbo.Person
SELECT 12002, REPLICATE(CAST('B' as nvarchar(max)),80000);
Exécution de la requête pour rechercher ces lignes insérées précédentes
SELECT TOP (2) *
from dbo.Person
where "id" = 1
or contains("lastName", '"B*"');
Cela entraîne à nouveau trop d'itérations sur presque toutes les lignes pour renvoyer la dernière valeur trouvée.
id lastname
1 'AAA...'
12001 'BBB...'
Résolution
Lors de la suppression de l'objectif de ligne à l'aide de traceflag 4138
SELECT TOP (5) *
FROM dbo.Person
WHERE "id" = 124
OR contains("lastName", '"B*"')
OPTION(QUERYTRACEON 4138 );
L'optimiseur utilise un modèle de jointure plus proche de l'implémentation de a UNION, dans notre cas, cela est favorable car il pousse les prédicats vers le bas vers leurs recherches d'index cluster respectives, et n'utilise pas l'opérateur de demi-jointure gauche ciblé par ligne.
Une autre façon d'écrire ceci, sans utiliser le traceflag mentionné ci-dessus:
SELECT top (5) *
FROM
(
SELECT *
FROM dbo.Person
WHERE "id" = 1
UNION
SELECT *
FROM dbo.Person
WHERE contains("lastName", '"B*"')
) as A;
Avec le plan de requête résultant:
où la fonction de texte intégral est appliquée directement
En guise de note, pour op, le correctif de l'optimiseur de requêtes traceflag 4199 a résolu son problème. Il a implémenté cela en ajoutant OPTION(QUERYTRACEON(4199))à la requête. Je n'ai pas pu reproduire ce comportement de mon côté. Ce correctif contient une optimisation de semi-jointure:
Indicateur de trace: 4102 Fonction: SQL 9 - Les performances de la requête sont lentes si le plan d'exécution de la requête contient des opérateurs de semi-jointure En règle générale, les opérateurs de semi-jointure sont générés lorsque la requête contient le mot clé IN ou le mot clé EXISTS. Activez les indicateurs 4102 et 4118 pour résoudre ce problème.
La source
Supplémentaire
Pendant l'optimisation basée sur les coûts, l'optimiseur peut également ajouter une bobine d'index au plan d'exécution, implémentée par LogOp_Spool Index on fly Eager (ou l'homologue physique)
Il le fait avec mon jeu de données pour TOP(3)mais pas pourTOP(2)
SELECT TOP (3) *
from dbo.Physician
where "id" = 1
or contains("lastName", '"B*"')
Lors de la première exécution, un spool impatient lit et stocke l'intégralité de l'entrée avant de renvoyer le sous-ensemble de lignes qui est demandé par les exécutions Predicate Later lire et renvoyer le même ou un sous-ensemble différent de lignes de la table de travail, sans jamais avoir à exécuter l'enfant nœuds à nouveau.
La source
Avec le prédicat de recherche appliqué à cette bobine impatiente d'index:
