Důležitá věc, kterou je třeba pamatovat při srovnávání výkonu úložiště MySQL v Linuxu, je mezipaměť. Sám jsem byl zvědavý na stejný testovací případ. Vždy je vtipné, když si uživatel stěžuje na pomalý dotaz. Zavolají vám a spustí se znovu, jen aby našli svůj 50+ minutový dotaz, který je nyní dokončen za 30 sekund kvůli mezipaměti dotazů. Vždy spusťte a
mysql> reset query cache;
v MySQL při pokusu o optimalizaci dotazů. To znamená, že při porovnávání SSD s tradičními vřeteny je ještě jeden krok:disková mezipaměť. Je obtížné porovnávat přístupové časy nebo IOps, když OS ukládá disk do mezipaměti sám. Chcete-li vymazat mezipaměť disku, spusťte z prostředí shell následující:
$ sync && sysctl -w vm.drop_caches=3
Tyto příkazy spuštěné před každým z vašich benchmarkových dotazů vám pomohou uvědomit si potenciál vašeho SSD ve srovnání s 7k2 SATA slowpoke, který máte. Ověřte to spuštěním stejného dotazu dvakrát bez vyprázdnění mezipaměti a sledováním časů dotazů. V tuto chvíli je dobré vyzkoušet některé dotazy s indexy a bez nich a také nějaká spojení, pokud je to možné. Použijte EXPLAIN PLAN v každém dotazu k ověření, že je použit index. Náhodný přístup při čtení mezi indexovými a datovými soubory odhalí úzká hrdla na pomalejších discích. Ujistěte se, že vaše my.cnf je konzistentní mezi vašimi SSD benchmarky a vaší plotnou. Testoval jsem některé věci na jednoduchém desktopovém OCZ SSD a všiml jsem si, že výkon dotazů se zvyšuje asi 10x rychleji než můj 7200rpm SATA disk. V transakční databázi založené na SSD bych byl při použití OPTIMIZE TABLE opatrný, protože časté zhušťování databáze v kombinaci s SSD TRIM může ovlivnit životnost disku. To je však teoretické a ještě jsem neviděl důkazy, které by to podpořily.
Snad to pomůže! Nemohu se dočkat dnů, kdy magnetické HD nahradí pásku jako záložní médium a ve většině hardwaru je zcela nahradí SSD.