En viktig sak att komma ihåg när man benchmarker MySQL-lagringsprestanda i Linux är cachen. Jag var själv nyfiken på samma testfall. Det är alltid roligt när en användare klagar på en långsam fråga. De ringer dig och kör igen bara för att se att deras 50+ minuters fråga nu slutförs på 30 sekunder på grund av frågecache. Kör alltid en
mysql> reset query cache;
i MySQL när du försöker optimera frågor. Som sagt, det finns ett steg till när man jämför SSD med traditionella spindlar:diskcache. Det är svårt att jämföra åtkomsttider eller IOps när operativsystemet cachar disk i minnet på egen hand. För att rensa diskcache, kör följande från ett skal:
$ sync && sysctl -w vm.drop_caches=3
Dessa kommandon körs före var och en av dina benchmark-frågor hjälper dig att inse potentialen hos din SSD jämfört med den 7k2 SATA-slowpoke du har. Verifiera detta genom att köra samma fråga två gånger utan att tömma cacheminnet och observera frågetider. Vid det här laget är det en bra idé att prova några frågor med och utan index, samt några kopplingar om möjligt. Använd EXPLAIN PLAN på varje fråga för att verifiera att ett index används. Slumpmässig åtkomst av läsning mellan index- och datafiler kommer att avslöja flaskhalsar på långsammare diskar. Se till att din my.cnf är konsekvent mellan dina SSD-riktmärken och din tallrik. Jag testade några saker på en enkel stationär OCZ SSD och märkte att frågeprestanda ökade med cirka 10 gånger så snabbt som min 7200rpm SATA-disk. I en SSD-baserad transaktionsdatabas skulle jag vara försiktig när jag använder OPTIMIZE TABLE eftersom frekvent databaskomprimering i kombination med SSD TRIM kan påverka diskens livslängd. Det är dock teoretiskt, och jag har ännu inte sett bevis som stödjer detta.
Hoppas det här hjälper! Jag kan inte vänta på de dagar då magnetiska HD-skivor ersätter tejp som backup-medium och blir helt ersatta av SSD i de flesta hårdvara.