MySQLのどの構成オプションが最大の速度改善を提供しますか?


29

MySQLのどの構成オプションが最大の速度改善を提供しますか?

実際の構成ファイルの改善、テーブルの種類、ハードウェアのセットアップ、レプリケーションなどについて疑問に思っています。クエリ構造とテーブル構造以外のものはすべて(WebサイトとStack Overflowで簡単に見つけることができます)。クエリキャッシュ設定のようなものが、あなたに最高の速度を与えましたか?ドライブはどうですか。外部RAIDまたは内部RAIDに配置する方が良いでしょうか?レプリケーションは、特に読み取りの大きなクエリでパフォーマンスを向上させましたか?

MySQLのパフォーマンスを改善するために、他にどのような設定/変更を加えましたか?

注:これらは使用量に非常に依存していること(つまり、小さなWebサイトとデータウェアハウス)を理解していますが、ほとんどの場合、おそらくさまざまなサイト/システムで作業していると思うので、さまざまな状況。また、いくつかの技術は状況間で移転できると思います。


完全に関連しているわけではありませんが、マスターにはInnoDBを使用する必要があります。MyISAMスレーブに複製し、組み込みの全文検索を使用して、LIKEよりもはるかに高速にテキスト検索を行うことができます
ニールマクギガン

回答:


20

ここに私の推奨事項があります(あなたのミレージは異なる場合があります)

  • ハードウェアRAIDを使用します。これは、他の投稿でソフトウェアRAIDを使用するという私の推奨に反しますが、これはハードウェアRAIDカードが必要な特定の状況です。具体的には、RAIDカードのバッテリーバックアップNVRAMを使用して、ログファイルをディスクにfsyncする時間を短縮します。
  • RAID 1またはRAID 10ボリュームのみを使用してください。RAID 5または6の書き込みコストは、読み取り/書き込みの混合ワークロードでは許容するには高すぎます。
  • データ、ログ、およびtmpボリュームに別々のLUNを使用します。これらはすべて、OSボリュームおよびスワップボリュームとは別にする必要があります。
  • InnoDBを使用します。
  • innodb_file_per_tableを使用する
  • 64ビットOSを使用する
  • InnoDBバッファープールを使用可能なRAMの〜80%に設定します
  • ログファイルをバッファプールサイズの1/4、つまり2〜4個のログファイルに設定します。ログファイルが大きいとシャットダウンと回復時間が遅くなりますが、大きなデータベースダンプをより速く復元できます。
  • log_slow_queries、log-queries-not-using-indexes、set-variable = long_query_time = 1、そのログ内のすべてのクエリを調査し、スキーマをリファクタリングして、可能な限りテーブルスキャンとtmpテーブルを回避します。

11

デイブ・チェイニーは、ここで本当に公園からそれをノックアウトしました。あなたの質問に対する彼の答えに何も追加することはできません。しかし、私はあなたが尋ねなかったものを指摘したいと思います。Jeremy ZawodnyとPeter Zaitsevが何年も前に教えてくれたように、悪いクエリの追跡と最適化に費やした時間のROIは、10倍の構成変更に費やした時間のROIを実行します。確かに、貧弱な構成、間違ったRAIDセットアップ、または不十分なRAMを持ちたくありません。しかし、優れた、さらにはわずかな、MySQL DBAの不適切なクエリ(通常はDBAではなく開発者/フレームワークから)は慢性的な状態であり、不適切な構成は耐えられるものです。

(私はしばらくの間それらの形容詞を掘りましたが、私が選んだものにまだ満足していません。)

開発者がRuby on RailsやDjangoなどのフレームワークで一般的なORMを使用している場合、DBにヒットするクエリを本当に監視する必要があることを強調しておきます。開発者がSQLについて考えるのをやめて、DBを抽象化させてしまうと、本当に厄介になります。先ほど触れた2つのフレームワークが大好きです。(口の悪いことで私を投票しないでください。)それは単にQuery Sleuthingを非常に重要にします。(読む:ジョブセキュリティ)


4

他のことはほとんどありません(Dave Cheneyの回答には記載されていません)

  • innodb_flush_methodをO_DIRECTに設定して、データの二重バッファリングを回避してください。RAIDカードにバッテリバックアップ式の書き込みキャッシュがない場合、またはデータがSAN上にある場合は、これを避けてください。

  • また、innodb_thread_concurrencyを試してください。デフォルトは8だと思いますが、これを微調整してパフォーマンスが向上するかどうかを確認する価値があります

  • クエリキャッシュがオンになっていることを確認し、統計をチェックしてヒット率を確認します。良い場合は、値を増やしてヒット率を改善するかどうかを確認してください。

  • 実行するアプリケーションによっては、デフォルトの分離レベルを変更できる場合があります。デフォルトはREPEATABLE_READですが、READ_COMMITTEDによりパフォーマンスが向上する場合があります

  • ステートメントの大部分がUPDATEおよびDELETEである場合、変更する結果セットを返すSELECTクエリを実行することにより、スレーブでキャッシュの準備を試みることができます。これを行うmk-slave-prefetchツールを確認してください

  • MyISAMおよびInnoDB以外の他のストレージエンジンをご覧ください



1

最初に行うべき一般的なことは、メモリパラメータを確認することです。MySQLのデフォルト設定は非常に控えめです。使用するエンジンが何であれ、多くのメモリパラメータを10倍または100倍も上げる必要があります。

次にすべきことは、テーブルキャッシュを調べることです。デフォルト値は64です。これは、テーブルが約60個以下の場合にのみ役立ちます。あなたはそれを長い道のりで育てたいと思うでしょう。

3番目にすべきことは、スレッドと接続パラメーターを確認することです。デフォルトのwait_timeoutは、ほとんどのWebベースのアプリケーションでは非常に長く、30秒程度に短縮できます。これにより、メモリの使用量も改善されます。MySQLは接続をより早く取得し、「スリープ」状態に陥るのをずっと少なくします。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.