En vigtig ting at huske, når man benchmarker MySQL-lagringsydelse i Linux, er cachen. Jeg var selv nysgerrig efter den samme testcase. Det er altid sjovt, når en bruger klager over en langsom forespørgsel. De ringer til dig og kører igen kun for at finde, at deres 50+ minutters forespørgsel nu er færdig på 30 sekunder på grund af forespørgselscache. Kør altid en
mysql> reset query cache;
i MySQL, når du forsøger at optimere forespørgsler. Når det er sagt, er der endnu et trin, når man sammenligner SSD med traditionelle spindler:diskcache. Det er svært at sammenligne adgangstider eller IOps, når operativsystemet cachelagrer disken i hukommelsen alene. For at rydde diskcache skal du køre følgende fra en shell:
$ sync && sysctl -w vm.drop_caches=3
Disse kommandoer kører før hver af dine benchmark-forespørgsler vil hjælpe dig med at realisere potentialet i din SSD sammenlignet med den 7k2 SATA slowpoke, du har. Bekræft dette ved at køre den samme forespørgsel to gange uden at skylle cache og observere forespørgselstider. På dette tidspunkt er det en god idé at prøve nogle forespørgsler med og uden indekser, samt nogle joinforbindelser, hvis det er muligt. Brug EXPLAIN PLAN på hver forespørgsel for at bekræfte, at der bruges et indeks. Den tilfældige adgang til læsning mellem indeks- og datafiler vil afsløre flaskehalse på langsommere diske. Sørg for, at din my.cnf stemmer overens mellem dine SSD-benchmarks og din plade. Jeg testede nogle ting på en simpel desktop OCZ SSD og bemærkede, at forespørgselsydeevnen steg omkring 10 gange så hurtigt som min 7200rpm SATA-disk. I en SSD-baseret transaktionsdatabase vil jeg være forsigtig, når jeg bruger OPTIMIZE TABLE, da hyppig databasekomprimering kombineret med SSD TRIM kan påvirke diskens levetid. Det er dog teoretisk, og jeg har endnu ikke set beviser, der understøtter dette.
Håber dette hjælper! Jeg kan ikke vente til de dage, hvor magnetiske HD'er erstatter tape som backup-medie og finder sig selv fuldstændig erstattet af SSD i det meste hardware.