[radioaktivitet]

Varje dag kör jag en UPDATE LOW_PRIORITY TABLE där jag uppdaterar ca 3000 rader i en tabell. Denna fråga tar knappt tre minuter att köra.

Under tiden ställs det, precis som vanligt, en mängd SELECT-frågor mot tabellen.

MEN. Efter en liten stund går det inte längre att ställa frågor mot tabellen. Då får man bara "Too many connections".

Vad kan detta bero på? Låser UPDATE tabellen för läsningar? Tabellen är av typen myisam eftersom jag har ett fritextindex på den. Men det borde väl inte ha någon betydelse?

Edit: det är en mysql-databas

[najk]

Som jag tolkat det: En update low_priority skriver inte ändringarna förens tabellen inte används, har den påbörjat att skriva ändringarna låser den tabellen tills det att den är klar med ändringarna, får du då många select samtidigt som skrivning sker köas dom upp och väntar på att den ska bli klar, det verkar som det är under denna tid du då får too many connections. Men när update är klar borde väl det flyta på som vanligt?

[hnn]

Verkar mer som om att du inte stänger anslutningarna mot databasen eftersom "Too Many Connections" inte har med tabellerna att göra.

Om tabellerna skulle vara låsta för skrivning eller läsning, så skulle sidan hänga sig istället eftersom han väntar på svar ifrån MySQL.

[Magnus_A]

Låter långsamt med en uppdatering som tar tre minuter att köra för 3000 rader.

Men om sidan hänger sig i väntan på svar så stängs väl inte anslutningarna eftersom scriptet inte löper färdigt annat än vid max execution time eller liknande, och då termineras skriptet utan att anslutningen stängs.

[radioaktivitet]

Ja. Sidorna hänger sig under denna tid.

Tittar jag i processkön så ser jag att det ligger en massa frågor som väntar på att få köras. Status är "blocked" om jag inte minns helt fel.

När update är klar så flyter det på som vanligt, ja.

Anledningen till att UPDATE tar lång tid är att tabellen är ganska stor och den är en join mellan två tabeller. Relevanta index finns, så där är det inte något problem. Join sker på primärnyckeln.

Menar ni alltså att detta är helt normalt?

[najk]

Ja det är helt normalt, du kanske kan köra updatering mot en temporär kopia av tabellen? Kan du köra uppdatering nattetid då det inte spelar någon roll?
Hur stor är ganska stor?

[radioaktivitet]

Grejen är att jag redan kör alla uppdateringar mot en temporär kopia.

Ca 10 miljoner rader är orginaltabellen. Det som uppdateras flyttas över till orginaltabellen via update. Ca 3000 rader uppdateras via denna update som är en join mellan den temporära tabellen och orginaltabellen.

Frågan ser ut så här:
UPDATE LOW_PRIORITY ORGTABLE O, TEMPTABLE T SET O.NAME = T.NAME WHERE O.ID = T.ID AND T.UPDATED = CURRENT_DATE

[radioaktivitet]

Eventuellt kanske det är bättre att köra den här frågan. Jag har inte riktigt förstått om den gör samma sak.

REPLACE DELAYED INTO ORGTABLE SELECT * FROM TEMPTABLE WHERE UPDATED = CURRENT_DATE

Nån som vet?

[Magnus_A]

Förutsatt att du har ett unikt index på ID i måltabellen och unika värden på ID i källtabellen så gör den ungefär samma sak.
Det som skiljer är om du har rader med ett ID i källtabell som ej finns i måltabellen så blir de tillagda till måltabellen i detta exempel men inte i förra, men det kanske du har täckt upp redan tidigare när du skapade din temporära tabell.

[radioaktivitet]

Det stämmer bra. Alla rader med ID i källtabellen finns i måltabellen.

Så du menar att även REPLACE frågan låser tabellen för läsning?