MySQL
Mysql Performance Tips

Välj Uttalningsoptimering

Nedan följer några tips att komma ihåg när vi skriver en utvald fråga i MySQL som kan hjälpa oss och minska vår frågetid: -

1. När vi använder var i en stor tabell bör vi se till att kolumnen där avsnittet är index eller inte. Ex: - Välj * från anställd där user_id> 2000. user_id om det indexeras kommer att påskynda utvärderingen av frågan atlot. Index är också mycket viktigt vid sammanfogningar och utländska nycklar.

2. När du behöver den mindre delen av innehållet snarare än att hämta hela data från tabellen, försök att använda gränsen. Skicka snarare Ex: - Välj * från anställd. Om du behöver bara 20 anställda från lakhs, använd bara gränsen Ex: - Välj * från anställd LIMIT 20.

3. Du kan också optimera din fråga genom att ange det kolumnnamn du vill ha i resultatset. Skicka snarare Ex: - Välj * från anställd. Nämn bara kolumnnamn från vilket du behöver data om du har massor av kolumner och du vill ha data för några av dem. Ex: - Välj id, namn från anställd.

4. Index kolumn om du använder för att verifiera för NULL i var klausul. Om du har något uttalande som VÄLJ * FRÅN tbl_name WHERE key_col IS NULL; sedan om key_col indexeras kommer utvärderingen att utvärderas snabbare.

Optimera lagringslayout för InnoDB-tabeller

1. I InnoDB har en lång PRIMÄRKNAPP (antingen en enda kolumn med ett långt värde eller flera kolumner som bildar ett långt sammansatt värde) slöser med mycket diskutrymme. Det primära nyckelvärdet för en rad dupliceras i alla sekundära indexposter som pekar på samma rad. Skapa en AUTO_INCREMENT-kolumn som primärnyckel om din primära nyckel är lång.
2. Använd datatypen VARCHAR istället för CHAR för att lagra strängar med variabel längd eller för kolumner med många NULL-värden. En CHAR (N) -kolumn tar alltid N-tecken för att lagra data, även om strängen är kortare eller dess värde är NULL. Mindre bord passar bättre i buffertpoolen och minskar disk I / O.

När du använder COMPACT-radformat (standard InnoDB-format) och teckenuppsättningar med variabel längd, som utf8 eller sjis, upptar CHAR (N) -kolumner en variabel mängd utrymme, men fortfarande åtminstone N-byte.

3. För tabeller som är stora eller som innehåller massor av upprepade text- eller numeriska data, överväg att använda KOMPRESSERAD radformat. Mindre disk I / O krävs för att föra data in i buffertpoolen eller för att utföra fullständiga tabellscanningar. Innan du fattar ett permanent beslut ska du mäta mängden komprimering du kan uppnå genom att använda KOMPRESSERAD kontra COMPACT radformat. Varning: Benchmarks visar sällan bättre än 2: 1-komprimering och det finns mycket overhead i buffertpoolen för KOMPRESSERAD.
4. När dina data når en stabil storlek, eller ett växande bord har ökat med tiotals eller några hundratals megabyte, överväg att använda OPTIMIZE TABLE-uttalandet för att omorganisera tabellen och kompaktera bortkastat utrymme. De omorganiserade tabellerna kräver mindre skiv I / O för att utföra fullständiga tabellscanningar. Detta är en enkel teknik som kan förbättra prestanda när andra tekniker som förbättrar indexanvändning eller inställning av applikationskod inte är praktiska. Varning : Oavsett tabellstorlek bör OPTIMERADE tabell endast sällan utföras. Det beror på att det är kostsamt och sällan förbättrar bordet tillräckligt för att vara värt det. InnoDB är ganska bra på att hålla sina B + träd fria från mycket avfallsutrymme.

OPTIMERA TABELL kopierar datadelen i tabellen och bygger om indexen. Fördelarna kommer från förbättrad förpackning av data inom index och minskad fragmentering inom tabellutrymmen och på disken. Fördelarna varierar beroende på uppgifterna i varje tabell. Du kanske finner att det finns betydande vinster för vissa och inte för andra, eller att vinsterna minskar med tiden tills du nästa optimerar tabellen. Denna operation kan vara långsam om tabellen är stor eller om indexen som byggs om inte passar in i buffertpoolen. Den första körningen efter att ha lagt till mycket data i en tabell är ofta mycket långsammare än senare körningar.

Bygga ett sammansatt index

I många situationer presterar ett sammansatt index bättre än ett index med en enda kolumn. För att skapa ett optimalt sammansatt index, fyll i det med kolumner i denna ordning.

• = kolumn (er) från WHERE klausulen först. (t.ex. INDEX(a,b,...) för WHERE a=12 AND b='xyz' ... )
• IN kolumn (er); optimeringsprogrammet kanske kan hoppa igenom indexet.
• Ett "intervall" (t.ex. x BETWEEN 3 AND 9 , name LIKE 'J%' ) Det kommer inte att använda någonting förbi den första intervallkolumnen.
• Alla kolumner i GROUP BY , i ordning
• Alla kolumner i ORDER BY , i ordning. Fungerar bara om alla är ASC eller alla är DESC eller om du använder 8.0.

Anteckningar och undantag:

• Duplicera inte några kolumner.
• Hoppa över alla fall som inte gäller.
• Om du inte använder alla kolumnerna i WHERE behöver du inte gå vidare till GROUP BY osv.
• Det finns fall där det är användbart att endast indexera kolumnen ORDER BY , och ignorera WHERE .
• "Dölj" inte en kolumn i en funktion (t.ex. DATE(x) = ... kan inte använda x i indexet.)
• "Prefix" -indexering (t.ex. text_col(99) ) kommer troligtvis inte vara till hjälp. kan skada.

Mer information och tips .