(som anvist lægger jeg en del af min kommentar i et svar, da det løste problemet)
Konverter EXISTS-udtrykkene til IN-udtryk.
Dette fungerer bedre i dette tilfælde, fordi forespørgslen nu effektivt vil blive evalueret "indefra og ud" begyndende med den forespørgsel, der indeholder din mest begrænsende faktor:fuldtekstsøgningsopslaget. Denne forespørgsel kommer til at returnere et lille sæt rækker, der kan slås direkte op mod den primære nøgle i den ydre forespørgsel (WHERE x in (SELECT X...)) i modsætning til at kalde den "indre" forespørgsel én gang pr. værdi af den ydre forespørgsel (eller for alle værdier i dit oprindelige tilfælde, hvis jeg læser det rigtigt). EXISTS-metoden her resulterer i Nested Loops (én evaluering af én forespørgsel for hver værdi i en anden) versus IN-metoden, der bruger Hash Joins (en meget mere effektiv udførelsesmetode i mange, hvis ikke de fleste, tilfælde).
Bemærk, at med EXISTS-metoden er der fire Nested Loops, der udføres med hver kørende mindst 3.000 gange. Den omkostning stiger. Selvom det ikke er en direkte sammenligning, kan du behandle indlejrede løkker, som du ville gøre FOR løkker i applikationskode:hver gang du kalder en indre løkke, stiger dit big-O-estimat en størrelsesorden:O(n) til O(n^ 2) til O(n^3), osv.
Hash Join er mere som et kort, hvor to arrays bliver trådt igennem på samme tid, og en operation udføres på begge. Dette er nogenlunde lineært (O(n)). Tænk på, at disse er indlejret som additiv, så det ville gå O(n) til O(2n) til O(3n) osv.
Ja, ja, jeg ved godt, at det ikke er helt det samme, men pointen er, at det at have flere indlejrede loops normalt indikerer en langsom forespørgselsplan, og at sammenligne de to big-O-stile gør det nemmere at genkende, tror jeg.
Nested Loops og EXISTS er ikke onde i sig selv, men i de fleste tilfælde, hvor der er en basisfilterbetingelse, der i sidste ende påvirker alt (f.eks. fuldtekstsøgningen i spørgsmålet), et IN-udtryk (eller i nogle). tilfælde, giver en ordentlig JOIN) en meget mere effektiv plan.