SQL Server 2005 TESTO LIBERO () problema di prestazioni

Question

Ho una domanda con circa 6-7 tabelle unite e FREETEXT () predicato su 6 colonne della tabella di base in cui.

Ora, questa ricerca ha funzionato bene (in meno di 2 secondi) per l'ultimo anno e praticamente rimasto invariato (ho provato le vecchie versioni e le persiste problema)

Così oggi, tutto ad un tratto, la stessa query dura circa 1-1,5 minuti.

Dopo aver verificato il piano di esecuzione in SQL Server 2005, la ricostruzione della FULLTEXT Indice di quel tavolo, riorganizzando l'indice FULLTEXT, creando l'indice da zero, riavviare il servizio di SQL Server, riavviare l'intero server non so cos'altro provare.

I temporaneamente la posizione la query per uso LIKE invece finché i questo numero (che richiede circa 6 secondi ora).

Quando guardo la query nel analizzatore di prestazioni delle query, quando metto a confronto il'FREETEXT'query con la query'LIKE', l'ex dispone di 350 volte di più letture (4.921.261 contro 13.943) e 20 volte (38937 vs . 1938) l'utilizzo della CPU di quest'ultimo.

Così è davvero la'FREETEXT'predicate che fa sì che sia così lenta.

Qualcuno ha ottenuto tutte le idee su quello che potrebbe essere il motivo? O ulteriori test ho potuto fare?

[Modifica]

Bene, ho appena eseguito la query di nuovo per ottenere il piano di esecuzione e ora ci vogliono 2-5 secondi ancora, senza le modifiche apportate ad esso, anche se il problema esisteva ancora ieri. E non è stato a causa di fattori esterni, come avevo smesso di tutte le applicazioni che accedono al database quando ho provato la questione Giovedi scorso, quindi non è stato a causa di eventuali altri carichi.

Bene, io sarò ancora includono il piano di esecuzione, anche se potrebbe non aiutano molto, ora che tutto funziona di nuovo ... E attenzione, si tratta di un enorme query a un database legacy che non posso cambiare (cioè normalizzare dati o di sbarazzarsi di alcuni tavoli intermedi non necessari)

piano di query

OK ecco la piena interrogazione

I potrebbe avere a spiegare che cosa esattamente fa. In sostanza si ottiene risultati di ricerca per annunci di lavoro, in cui ci sono due tipi di annunci, quelli premium e quelli normali. i risultati sono paginate a 25 risultati per pagina, 10 quelli premium sulla parte superiore e 15 quelli normali dopo che, se non ci sono sufficienti.

quindi non c'è due query interne che selezionano come molti di quelli premium / normali, se necessario (ad esempio, a pagina 10 si va a prendere i primi 100 quelli premium e top 150 quelli normali), poi quelle due query sono intercalati con un comando () row_number e un po 'di matematica. allora la combinazione è ordinato dal RowNumber e la query viene restituito. Beh, è ??utilizzato in un altro luogo per ottenere solo i 25 annunci necessari per la pagina corrente.

Oh, e tutta questa query è costruito in un file enorme eredità Coldfusion e come è stato lavorando bene, non ho osato thouching / modifica grandi porzioni finora ... non toccare mai un sistema in esecuzione e così via;) Basta piccola roba come cambiano bit della centrale dove clausola.

Il file genera anche altre query che fanno fondamentalmente la stessa, ma senza il / distinzione premio di non premium e un sacco di altre varianti di questa query, quindi sono mai del tutto sicuro di come una modifica a uno di loro potrebbe cambiare la altri ...

Ok come il problema non è emerso ancora una volta, mi ha dato Martin la generosità come lui è stato il più utile finora e non volevo la bontà per scadere inutilmente. Grazie a tutti gli altri per i loro sforzi, proverò i vostri suggerimenti se succede di nuovo:)

Answer 1

Questo problema potrebbe verificarsi a causa di una stima di cardinalità poveri del numero di risultati che verrà restituito dalla query testo completo che porta a una povera strategia per le operazioni JOIN.

Come si fa a trovare le prestazioni se si interrompe in 2 passi?

Un nuovo passo che popola una variabile di tabella o una tabella temporanea con i risultati della query full-text e la seconda cambiare la query esistente per fare riferimento alla tabella temporanea, invece.

(NB: Si potrebbe desiderare di provare questo ENTRA con e senza OPTION(RECOMPILE) mentre guardando i piani di query per (A) un testo termine di ricerca gratuito che restituisce molti risultati (B) Uno che restituisce solo una manciata di risultati.)

Modifica E 'difficile da chiarire esattamente in assenza della query incriminata, ma quello che voglio dire è invece di fare

SELECT <col-list>
FROM --Some 6 table Join
WHERE FREETEXT(...);

Come funziona questo esegue?

DECLARE @Table TABLE
(
<pk-col-list>
)
INSERT INTO @Table
SELECT PK
FROM YourTable
WHERE FREETEXT(...)

SELECT <col-list>
FROM --Some 6 table Join including onto @Table
OPTION(RECOMPILE)

Answer 2

Di solito, quando abbiamo questo problema, è a causa della tabella di frammentazione e le statistiche stantie sugli indici in questione.

La prossima volta, cercare di EXEC sp_updatestats dopo una ricostruzione / reindex.

utilizzo di statistiche per migliorare le prestazioni delle query per maggiori informazioni.