「IP男」を形成、または質問をするか、議論ができると私たちは簡単に破片を活用するように、日中の回答を公開していない、あなたのヒントや技術的な知識を提供するために、随時、教会の新たに設計されたインタラクティブな部品の数を知ることです時間は最も実用的な知識を学ぶことができます。
2018年12月4日（火）
大きなテーブル、インデックスなしの列、その列を最初に確認する必要が、レコードを削除する基準を満たし、データ量の40％を中心に、私はより良い計画は何です求めることができますか？
I.ときに別の索引（主キー、ユニークインデックス、通常のインデックス）
図1は、そのような読み取り専用すべての1000個のレコードとして既存のインデックスのフルテーブルスキャンセグメントを利用し、その後条件に応じて判断し、データ（アーカイブ好ましくはなく、実際には削除）を削除してもよいです。
2は、原因削除されたデータのより多くの量に、InnoDBのテーブルが断片化されている、あなたが過去に残しておきたいデータをコピーし、新しいテーブルを作成、つまり、逆の操作を使用することを検討して発生し、その後、最後の2つのテーブルが逆転しました。
3、PT-アーカイバアーカイブツールを使用して。
第二に、いずれの指標ケースなし
図1は、これは本当に起こる、DBAまたは関連のトラブルの責任の学生が今辞任します。この文は冗談、ちょっと、本当にあまりにも痛手です。
図2は、より高い識別（複数の異なる値）場合は、新しいインデックスを作成するために、列挙された条件を表示し、その後、インデックスに従ってデータを削除します。
図3に示すように、テーブルは、（アーカイブ）を削除し、決定し、主キー索引スキャン区間に応じて、プライマリ・キー列、及び上述した実施形態を参照することによって作成されるため
2018年12月11日（火）
MySQLは、この現象は、解決する方法を変更する理由を1個のCPUコア、上のすべての圧力を持っていますか？
まず、なぜこのような現象でしょうか？
MySQLは、並列コンピューティングをサポートしていないため、実際には、すべての圧力は、すべて一つの論理CPU上で、実際には、そのセッションのSQLは論理CPUに割り当てられますされています。
なぜなら、高確率のこの現象の理由は、以下の状況：
1、セッションが遅いSQLを実行している、まだ終わっていません。
2は、SQLでのセッションは大きなトランザクションを開き、行ロックの多くを保持しているか、多くの行ロックを待機し、トランザクションがまだ終わっていません
第二に、どのように解決するには？
1.遅いSQLの確認、および最適化
2、小さなトランザクションに分割、大規模なトランザクションを使用しないようにしよう
3、mysqldプロセスは、CPUが高い消費する場合、確率はいくつかのSQLインデックスがをもたらさなかったこと素晴らしいです古いと言って、ドライバを覚えています
4、なぜトップツールperfの使用はまた、特定の原因のトラブルシューティングをしようとすることができます
2018年12月18日（火）
MySQLのパフォーマンスを監視、我々はいくつかのメインモニタ項目を観察する必要がありますか？
、liunxオペレーティング・システム・レベル
図1に示すように、全体的なCPU負荷％のユーザの最良の長期的20％以下（％ユーザーが高すぎる場合、インデックスの不適切な使用の可能性が高いです）
2、（明らかなボトルネックのためにI / Oサブシステムの）好ましくは10％以上、長期全体的な負荷のCPU％のiowat
3、％アイドル状態のCPUの全体的な負荷は少なくとも70％を維持することが最良である（CPUが低負荷残ることを可能）
図4に示すように、各論理CPUとの間の負荷を懸念は、平衡である（不均衡の原因のパフォーマンスの問題を中断されていてもよいです）
vmstatの、SAR、DSTAT等：生成スワップ（注NUMA閉鎖）があるか否かを、コマンドまたはツールを使用する懸念5、
二、MySQLの状態レベル
図1に示すように、主な関心事のTPS、QPS、同時（Threads_connected）接続数、同時アクティブなスレッドの数（Threads_running）、一時テーブル（* tmp_disk_tables *）、ロック（*、* Innodb_row_lock locks_waited）および他の指標
コピー*へ* TMPテーブル、ソートインデックスの作成、結果の並べ替え、TMPテーブルの作成、および限りデータを送信する：例えば、スレッドの現在の貧しい状態が、かどうかを心配2、
3、* InnoDBのバッファプールページの使用、主にInnoDBの懸念pages_free、InnoDBの* wait_free 2
4、InnoDBの懸念は、リフレッシュの遅れ、特にチェックポイント遅延、および注意unpurgeリストのサイズをREDOログ
5.長いセマフォの場合の懸念のInnoDBのステータスが待ち時間が表示されます
6、成長スロークエリのSQLへの配慮