LinuxでMySQLストレージのパフォーマンスをベンチマークするときに覚えておくべき重要なことはキャッシュです。私自身も同じテストケースに興味がありました。ユーザーが遅いクエリについて不平を言うとき、それはいつも面白いです。彼らはあなたに電話して再実行しますが、クエリキャッシュがあるため、50分以上のクエリが30秒で完了するようになりました。常に
を実行しますmysql> reset query cache;
MySQLでクエリを最適化しようとするとき。そうは言っても、SSDを従来のスピンドルと比較する場合、もう1つのステップがあります。それはディスクキャッシュです。 OSが独自にメモリにディスクをキャッシュしている場合、アクセス時間またはIOPSを比較することは困難です。ディスクキャッシュをクリアするには、シェルから次のコマンドを実行します。
$ sync && sysctl -w vm.drop_caches=3
これらのコマンドは、各ベンチマーククエリの前に実行されるため、7k2SATAスローポークと比較してSSDの可能性を理解するのに役立ちます。キャッシュをフラッシュせずに同じクエリを2回実行し、クエリ時間を監視して、これを確認します。この時点で、インデックスの有無にかかわらずいくつかのクエリを試し、可能であればいくつかの結合を試すことをお勧めします。各クエリでEXPLAINPLANを使用して、インデックスが使用されていることを確認します。インデックスファイルとデータファイル間の読み取りのランダムアクセスは、低速のディスクのボトルネックを明らかにします。 my.cnfがSSDベンチマークとプラッターの間で一貫していることを確認してください。シンプルなデスクトップOCZSSDでいくつかのことをテストしたところ、クエリのパフォーマンスが7200rpmSATAディスクの約10倍の速さで向上していることがわかりました。 SSDベースのトランザクションデータベースでは、OPTIMIZE TABLEを使用する場合は注意が必要です。これは、SSDTRIMと組み合わせたデータベースの頻繁な圧縮がディスクの寿命に影響を与える可能性があるためです。それは理論的なことですが、これを裏付ける証拠はまだありません。
お役に立てれば！磁気HDがバックアップメディアとしてテープに取って代わり、ほとんどのハードウェアでSSDに完全に取って代わられる日が待ちきれません。