mysql最適化テーブルの適切な使用
MySQLデータベースのバージョン5.5/6を維持し、InnoDBを使用するためのベストプラクティスを考えたいと思います。
私はこれに出くわしました 記事 これは基本的に最適化テーブルを言っています：
- クエリでPKが使用されない場合は、大幅な改善は見られません。
- テーブルの他のインデックスは疑似ランダムな順序で作成され、ほとんどの場合、最適化テーブルの恩恵を受けません。
- 変更ごとにページ分割が発生する可能性が高くなるため、実際には更新が遅くなる可能性があります。
私の質問は：
- 上記の3つの点は常に正しいですか？部分的に？どういたしまして？
- いつテーブルを最適化するのが良いショットですか？
- どのような場合にテーブルを最適化してもメリットがなく、テーブルの一部の用途が悪化するだけでしょうか？
- PK以外のテーブルのインデックスを最適化する方法はありますか？
その投稿の著者であるバロンシュワルツは、MySQLのパフォーマンスに関して最も優れた本の1つである High Performance MySQL、3rd Edition の共著者の1人です。権威の主張は必ずしも良いものではありませんが、おそらく彼は自分の言っていることを知っていると思います。
彼の言うことはすべて正しいですが（私の控えめな意見では）、実際の根本的な議論を理解する必要があります：InnoDBテーブルのデフラグは多くの場合（パフォーマンスのために）役に立たず、頻繁に行うことを推奨する多くの人々は間違っています。
断片化とページ分割はデリケートなトピックであり、Jeremy Coleのような人々はそうです http://blog.jcole.us/2013/04/09/innodb-bugs-found-during-research-on-innodb-data -storage / およびFacebookエンジニアは多くのこと（特に圧縮に関して）を言及しています： https://www.facebook.com/note.php?note_id=101503483154559 とパフォーマンスへの影響。
多くの場合、パフォーマンスは負荷に依存します。自動インクリメントを使用して挿入しますか？テーブルの途中で何度も挿入と削除を行いますか？テーブルが非常に動的である場合、追加のディスク領域を確保できますか？
私があなたに推奨できるいくつかの良い習慣があります（これはおそらくあなたが望むものです）：
- 多数のレコードのバッチDELETEを実行した場合（そしてそれらを元に戻すつもりがない場合）のみ、デフラグを実行してください。他の場合では、それは必要ないかもしれません。論理データとファイルサイズの間に大きな違いがあるかどうかを知りたい場合は、.idbファイルをshow table statusのdata + index sizeと比較します。
- 常にプライマリキーの順序で挿入することで挿入を高速化し、不要なページ分割を強制しないようにします。
- パーティション化を使用して、テーブルの内部構造を変更する可能性のある変更を分離します。
- 「セカンダリインデックスを最適化する」方法はありませんが、そのようなことを必要とすることは決してありません。変更バッファーは、インデックスへの変更/リバランスが非同期で行われ、大きなパフォーマンスの問題がないことを確認します。 BTREEは常にバランスを取る必要があるため、変更バッファーがいっぱいではなく、パージスレッドが古い行レコードをすぐに削除すると想定すると、パフォーマンスは問題ありません。 「セカンダリインデックスの最適化」と呼ぶことができる1つの方法は、インデックスを削除して再作成することです（InnoDBプラグインまたはMySQL 5.5+を使用していることを想定しています）。それをする理由は全くありません。
もちろん、本当にこのトピックを掘り下げたい場合は、いくつかのテーブルを作成し、それらをデフラグして、後で実際に利益があるかどうかを確認します。一般に、テーブルスペースの処理と統計の収集は、InnoDBでは比較的自動的に行われます。