FAQ |
Kalender |
![]() |
#1 | ||
|
|||
Flitig postare
|
Jag har en ganska fet tabell med flera miljoner rader, myisam. På detta har jag ett fulltextindex. Fritextsökningarna går för det mesta väldigt snabbt. Men en del fritextsökningar, som är väldigt generella, tar lång tid. Och i dessa fall så verkar tabellen låsas - så att andra frågor (även frågor på en viss rad, dvs med unik nyckel) hamnar som LOCKED i processlistan.
Jag har tänkt att flytta ut själva fritextsökningen till sphynx. Men framtillsdess - vad kan jag göra åt problemet? Är det ö.h.t. normalt att en fritextsökning låser tabellen? Obs, jag har tillfälligt stängt av alla inserts och updates på denna tabell. Så jag är helt säker på att det är fritextsökningarna som är "flaskhalsen". Jag kör mysql 5 om det har någon betydelse. Tacksam för hjälp. |
||
![]() |
![]() |
![]() |
#2 | ||
|
|||
Mycket flitig postare
|
Det är inte så att det är en jobbig select som ställs och sen en update/insert/replace/delete efter. Det gör att den update/insert/replace/delete måste vänta och sen alla selects efter måste vänta på queryn som ändrar.
|
||
![]() |
![]() |
![]() |
#3 | ||
|
|||
Flitig postare
|
Nej. Jag har stängt av alla update/insert/replace/delete. Så jag är säker på att det endast är en fritext select som ställer till problemet...
|
||
![]() |
![]() |
![]() |
#4 | ||
|
|||
Klarade millennium-buggen
|
Jag *tror* fritextsökningarna läser in indexet i ramet, det kan ta ett tag. Kolla din io med vmstat eller gkrellmd eller nåt.
Om mysql läser in indexet är det väl rätt rimligt att tro att den låser tabellen under tiden indexet är på väg in i ram. Jag skulle definitivt byta till sphinx med så mycket data. |
||
![]() |
![]() |
![]() |
#5 | ||
|
|||
Klarade millennium-buggen
|
Hur ser dina index ut för tabellen? Är indexet med fulltext fullt optimerad? Hur ser frågan ut?
|
||
![]() |
![]() |
Svara |
|
|