Kontakta supporten

Vi svarar via e-post, oftast inom två dagar.

Google reCAPTCHA kontrollerar det här inskicket mot missbruk; data skickas till Google. Skriptet laddas först när formuläret öppnas.

← Alla inlägg

När ett extra index gör saker långsammare

Tabellen med dagliga siffror har en enda nyckel: räknaren och datumet tillsammans. Fem ställen i koden ställer en annan fråga till den — inte ”den här räknaren över tid” utan ”alla räknare på de här datumen”. Galleriet på startsidan, topplistan, webbplatskartan, ett 90-dagarsdiagram och statussiffrorna. Utan ett index på datumkolumnen läser vart och ett av dem alla 114 113 rader.

Med det indexet blir galleriet tio gånger snabbare. Det lades ändå inte till. Här är mätningen som avgjorde saken.

galleri, en dag — 61,5 till 6,1 ms topplista, 30 dagar — 88,6 till 89,2 ms webbplatskarta, 14 dagar — 79,6 till 94,8 ms 90-dagarsdiagram — 120,0 till 109,2 ms statussiffror, 365 dagar — 204,9 till 225,1 ms övre stapeln utan indexet, nedre stapeln med det totalt: 555 ms blir 524 ms

En fråga blev mycket snabbare

Galleriet frågar efter de räknare som var aktiva i dag. Utan index på datumet läser det igenom hela tabellen; med ett index slår det upp ett enda datum och läser 443 rader. 61,5 millisekunder blev 6,1. Det är inget subtilt resultat, och om det hade varit det enda som mättes skulle indexet finnas i databasen nu.

Två frågor blev långsammare

Webbplatskartan frågar efter fjorton dagar och blev 19 % långsammare. Statussiffrorna frågar efter ett år och blev 10 % långsammare. I båda fallen bytte frågeplaneraren från primärnyckeln till det nya indexet och gjorde ett sämre val.

Det här är den del som är värd att förstå, eftersom det inte är en bugg i planeraren. Att läsa ett intervall via ett sekundärindex innebär att hitta de matchande raderna i indexet och sedan hämta var och en från tabellen. För ett smalt urval är det ett fynd. För fjorton dagar av tretton månader är det fortfarande många rader som hämtas en i taget, och en rak genomläsning av tabellen — i fysisk ordning, vilket är vad diskar och cacheminnen gillar — slår det. Planeraren vet inte det. Den ser ett intervall och ett index och tar det.

Det finns inget sätt att säga ”använd det här indexet bara för galleriet”. Ett index är tillgängligt för varje fråga som berör kolumnen, och planeraren använder det överallt där dess uppskattningar säger att den borde. Att lägga till ett index är en ändring av varje fråga mot den tabellen, inte bara av den fråga det var avsett för.

Sammantaget: ingenting

Över alla fem blev 555 millisekunder 524. En förbättring på 1,1×, vilket på en liten server som ändå levererar de här sidorna från en cache inte är värt en ändring av schemat.

90-dagarsdiagrammet ser ut att ha förbättrats med 9 %. Det räknas inte, och det är värt att säga varför. Varje fråga mättes i tre omgångar: utan indexet, med det och sedan utan det igen. Om den andra körningen utan index inte hamnar nära den första var det maskinen som gjorde skillnaden, inte ändringen. För 90-dagarsdiagrammet skilde sig de två körningarna utan index åt med 13,8 % — mer än den effekt som påstods. Den raden mäter alltså ingenting, och den redovisas som ingenting.

Hur det här mättes, och varför det spelar roll

Inte på den skarpa tabellen. Skriptet kopierar den, arbetar på kopian och tar bort kopian i slutet. Att lägga till ett index i en produktionstabell för att se vad som händer fungerar bara en gång per överraskning.

Frågorna är de riktiga, hämtade direkt ur koden, inklusive joinen mot räknartabellen. En tidigare version av testet använde en förenklad ersättare och gav ett mycket mer spännande svar: tjugo gånger snabbare. Den förenklade frågan var inte en som något faktiskt kör.

Vad siffran skulle ha blivit

Om det här hade mätts på det vanliga sättet — ta frågan som känns långsam, ta tid före och efter — hade svaret blivit ”tio gånger snabbare, in med det”. Indexet hade lagts till, galleriet hade blivit snabbare, webbplatskartan och statussidan hade blivit långsammare, och ingen hade kopplat ihop de två sakerna, eftersom ingen tittade på dem.

Det är det allmänna mönstret. En ändring i delad infrastruktur kan inte bedömas utifrån det fall som motiverade den. Frågan är inte ”hjälper det här det jag tittar på” utan ”vad mer berör det här, och vad händer med det”.

Det finns en variant som skulle kunna fungera: ett index med båda kolumnerna, datumet först, så att galleriet kan besvaras enbart ur indexet utan att gå tillbaka till tabellen. Det kanske också slipper locka planeraren vid de bredare intervallen. Det har inte mätts, så det är ingen rekommendation — det är nästa sak att prova på kopian.

Annons