sql >> Databasteknik >  >> RDS >> Mysql

MySQL-partitionering / sönderdelning / delning - vilken väg ska jag gå?

Du kommer definitivt att börja stöta på problem på det där 42 GB-bordet när det inte längre får plats i minnet. Faktum är att så fort den inte får plats i minnet längre kommer prestandan att försämras extremt snabbt. Ett sätt att testa är att placera den tabellen på en annan maskin med mindre RAM och se hur dålig den fungerar.

Detta är felaktigt. Partitionering (antingen genom funktionen i MySQL 5.1, eller samma sak med MERGE-tabeller) kan ge betydande prestandafördelar även om tabellerna är på samma enhet.

Som ett exempel, låt oss säga att du kör SELECT-frågor på ditt stora bord med ett datumintervall. Om tabellen är hel, kommer frågan att tvingas skanna igenom hela tabellen (och vid den storleken kan även användning av index vara långsam). Fördelen med partitionering är att dina frågor bara körs på de partitioner där det är absolut nödvändigt. Om varje partition är 1 GB stor och din fråga bara behöver komma åt 5 partitioner för att uppfylla sig själv, är den kombinerade 5 GB-tabellen mycket lättare för MySQL att hantera än en monsterversion på 42 GB.

En sak du måste fråga dig själv är hur du frågar efter data. Om det finns en chans att dina frågor bara behöver komma åt vissa bitar av data (t.ex. ett datumintervall eller ID-intervall), kommer partitionering av något slag att visa sig fördelaktigt.

Jag har hört att det fortfarande finns en del buggy med MySQL 5.1-partitionering, särskilt relaterat till att MySQL väljer rätt nyckel. MERGE-tabeller kan ge samma funktionalitet, även om de kräver något mer overhead.

Hoppas det hjälper...lycka till!



  1. Lösning för ORA-00997:olaglig användning av LONG datatyp

  2. Fel när QUERY-paketet skickades

  3. MySQL-fråga med limit och stor offset som tar för evigt

  4. Fel vid infogning i sql-databasen med php