sslug-teknik team mailing list archive

[Martin Berg <martin@xxxxxxx>]

Robert Larsen wrote:
> Hey
> 
[klip]
> 
> Hvordan kan det være, at den version, som bruger index tager mere end 10
> gange så lang tid som den version, der IKKE bruger index ?
> Jeg har også prøvet med andre ord så jeg kunne være sikker på, at MySQL
> ikke brugte query cache eller omskrev mit query.
> 
> VH
> Robert
> 

<wild guessing>

At indexere tekst er meget forskelligt fra at indexere
almindelige nøgler.
Uden at kende til MySQLs implementering, vil jeg antage at
det er en kombination af en ordliste og en liste af referencer til
rækker i tabellen - i modsætning til et normalt index, hvor man
til hver nøgleværdi direkte kan tilknytte referencer til de
relevante rækker.

Denne antagelse vil betyde at der når man har fundet frem
til det relevante ord i ordlisten, så skal referencerne til
rækkerne findes et andet sted - og dette er sandsynligvis
en operation per række FØR man står med en reference til
rækken.

Dette er forskelligt fra det almindelige index (i den form
jeg kender) hvor referencerne til rækkerne er repræsenteret
som en liste i umiddelbar fysisk sammenhæng med nøgleværdien.

Hvis min antagelse om MySQL's implementering af fulltext index
er korrekt, så vil du i dit eksempel generere 5127025 operationer
til at finde refererencer til rækker i tabellen.

5127025 gange en kort operation (hvoraf nogle af disse måske endda
resulterer i I/O) kan meget vel blive til 33 sekunder.

</wild guessing>

Hvor meget fylder din tabel iøvrigt ?
Din tekstkolonne skal nemlig ikke være særlig stor, før der
må være tale om væsentligt mere end 100MB - og så begynder vi
at nærme os at den relevante del af datafilen, som indeholder
tabellen må være cachet i filsystem-cachen, ellers kan det dårligt
lade sig gøre at skanne hele tabellen igennem på mindre end 3 s.
I/O tager trods alt et stykke tid.
(men du har måske et disksystem, som er stripet over et antal
SSD :-)


/Martin Berg