join_buffer_size> = 4 Mは推奨されませんか？
MysqlTunner.plからこのメッセージを受け取ります。
join_buffer_size> = 4 Mこれはお勧めできません
一方、私はjont_buffer_sizeについてDebianのmy.cnfガイドを読みました：
このバッファは、完全なJOIN（インデックスのないJOIN）の最適化に使用されます。このようなJOINは、ほとんどの場合、パフォーマンスにとって非常に悪いですが、この変数を大きな値に設定すると、パフォーマンスへの影響が軽減されます。完全なJOINの数については、「Select_full_join」ステータス変数を参照してください。完全結合が見つかった場合、スレッドごとに割り当てられます
だから、どれを信じたらいいのかしら？現在、クエリが特に最適化されていない高トラフィックサイトのスケーラビリティの問題に対処するための取り組みの一環として、join_buffer_size = 64Mを設定しています。これについてのヒントに感謝します。
join_buffer_size = 64MBはちょっとおかしいです。つまり、新しいスレッドごとに+ 64MBが割り当てられます。
プレーンインデックススキャン、レンジインデックススキャン、およびインデックスを使用せず、フルテーブルスキャンを実行する結合に使用されるバッファのサイズ。通常、高速結合を実現する最良の方法は、インデックスを追加することです。インデックスの追加が不可能な場合は、join_buffer_sizeの値を増やして、完全な結合を高速化します。
つまり、テーブルにインデックスを追加し、保存したメモリを使用してjoin_buffer_sizeを+ _10xに増やしながら、128Kを256Kとkey_buffer_sizeの間の値に減らす必要があります。
メモリが増えても、速度が上がるとは限りません。一般的な例は、sort_buffer_size、read_buffer_size、read_rnd_buffer_size、table_open_cacheです。グーグルそれ。
彼らは私に同じことを言っているようです。彼らは両方ともあなたにFULL JOINS are BADと言っています。
- Mysqltunerは、システムについて何かが悪いことを指摘しています。この場合、大きな結合バッファーを用意する必要があることは、データベースについて何か悪いことを示しています。
- ドキュメントはそれが悪いことを伝えていますが、コードを変更できない場合は、メモリを追加すると問題を受け入れることができます。
Select_full_join変数を確認しましたか？このカウンターの増加を実際に見ていますか？コードを修正するか、それを修正する責任のある人に怒鳴るのは選択肢ではありませんか？
接続ごとのバッファを増やさないでください！
My.cnfのすべてのバッファがサーバーインスタンスに1回だけ割り当てられるわけではありません。一部のバッファは、接続ごとに割り当てられます。 https://haydenjames.io/my-cnf-tuning-avoid-this-common-pitfall/ で詳細をご覧ください。
見積もり：
Join_buffer_size、sort_buffer_size、read_buffer_size、read_rnd_buffer_sizeなどのバッファは、接続ごとに割り当てられます。したがって、read_buffer_size = 1Mおよびmax_connections = 150の設定は、MySQLに起動時から接続ごとに1MB x 150接続を割り当てるように要求しています。 10年以上の間、デフォルトは128Kのままです。デフォルトを増やすことは、サーバーのメモリを浪費するだけでなく、パフォーマンスの向上にもつながりません。ほとんどすべての場合、これらの4つのバッファー構成行を削除またはコメント化してデフォルトを使用するのが最善です。より段階的なアプローチでは、それらを半分に減らして無駄なRAMを解放し、時間の経過とともにデフォルト値に向かって減らしていきます。これらのバッファを減らすことで、スループットが向上したことを実感しました。ただし、トラフィックが非常に多い場合やその他の特別な状況を除いて、これらのバッファを増やしてもパフォーマンスは向上しません。これらを勝手に増やすことは避けてください！
メモリアクセスの速度
一般的なロジックとは異なり、メモリへのアクセスはO（1）ではありません。
より多くのRAMあなたが持っている、遅いのはこのRAMのデータへのアクセスです。
そのため、less RAMを使用すると、実際にRAMへのより高速なアクセスが提供される可能性があります-これは、MySQLにのみ適用されるのではなく、一般的な規則です。 RAM-ランダムメモリの読み取りがO（√N） である理由
MySQLのjoin_buffer_sizeに戻りましょう。
MySQLのjoin_buffer_sizeのチューニング
Join_buffer_sizeは、2つのテーブル間の完全結合ごとに割り当てられます。 MySQLのドキュメントから、join_buffer_sizeは次のように記述されています。 「グローバルサイズがそれを使用するほとんどのクエリで必要とされるよりも大きい場合、メモリ割り当て時間がパフォーマンスの大幅な低下を引き起こす可能性があります。」結合でインデックスを使用できない場合、結合バッファはテーブル行をキャッシュするために割り当てられます。データベースがインデックスなしで実行される多くの結合の影響を受ける場合、join_buffer_sizeを増やすだけでは解決できません。問題は「インデックスなしで実行される結合」であり、したがって、より高速な結合の解決策はインデックスを追加することです。
MySQLの設定を変更して、インデックスのないクエリをログに記録します。そうすることで、そのようなクエリを見つけてインデックスを追加したり、送信するアプリケーションを変更したりして、このような悪質なクエリを生成することができます。 「log-queries-not-using-indexes」を有効にしてから、スロークエリログでインデックスなしの結合を探します。
私はそうは思いません。おそらくmysqltunerは、必要に応じて、構成に基づいた構成を提案します。 mysqltunerをDBサーバーで実行した場合。ここで私が得ることが推奨されます：
Variables to adjust:
*** MySQL's maximum memory usage is dangerously high ***
*** Add RAM before increasing MySQL buffer variables ***
join_buffer_size (> 64.0M, or always use indexes with joins)
innodb_buffer_pool_size (>= 54G) if possible.
innodb_log_file_size should be (=2G) if possible, so InnoDB total log files size equals to 25% of buffer pool size.
だから私はそれが別のサーバーで常に悪いサイズであるとは限らないと思います。
INDEXESのないJOINSは、分析と適切なインデックス作成で解決する必要があります。
Mysqlcalculator.comをjoin_buffer_sizeと共に使用して、メモリ要件への影響を確認します。劇的な結果を得るには、1分もかかりません。