[an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] (none) [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive]
[an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] (none) [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive]![]() |
![]() |
![]() |
|||||||||||||||||||||||||
|
|||||||||||||||||||||||||||
![]() |
![]() |
![]() |
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
![]() |
![]() |
![]() |
||||||||||||
|
||||||||||||||
![]() | ||||||||||||||
|
||||||||||||||
![]() |
![]() |
![]() |