背景
彼らは与えるので、数多くの人々の後に研磨、突然MySQLデータベース本番環境では、あまりにも多くの接続リンクの多くを開き、2時間のサイト全体の麻痺につながる、サイトにアクセスできません、我々は比較的大規模なプロジェクトので、無駄にデータベースサーバの再起動を再起動します調査はいくつかの困難をもたらしたので、調査は2時間の下で長い時間を解決するために、空まとめたものでアイデアや方法でした。
MySQLのエラーログ
初回は、このような問題が発生し、それが大体捜査の方向を以下、避けられない感じの無力です：
オンラインプロセスを見て、SQL操作を参照してください、最長実行を参照してください、SQL状態を参照してください。
トラブルシューティング
方向1：これは、提案された：MAX_CONNECTIONSこの値は、一時的に最初のいくつかの問題を解決する大きなに変更することができます。実際には、ここでの大きな変化は、あまり意味がありませんでした主にプロセスSQLの問題を発見することが推定深刻なバグ、です。
方向2：コマンドshow PROCESSLISTを実行
注：ショーPROCESSLISTは、ユーザーが実行中のスレッドで、rootユーザーに加えて、他のユーザーが唯一の独自のスレッドが実行されている見ることができ、外を実行しているすべてのスレッドを見ることができることに留意すべきである、他のユーザーは、実行中を見ることができませんスレッド。これだけでは、ユーザーが許可処理を与えない限り。
3つの方向：「％タイムアウト％」コマンドのように実行するショー変数
ビューのタイムアウト、またはロックされた状態。多数を使用しますが、ロックされていない：それは結論付けました。
方向4：statusコマンドのInnoDB実行ショーエンジン
ことを示しているエンジンInnoDBのステータスを示してどのくらいの情報システムの状態つまり、あなたが見てください方法がわからない場合は、このブログを
SQLすでにオーバー占有、コピーTMPテーブルを持っている数が増加している接続し、プールをバッファリングすることが見出されて。
現在のSQLプロセスを表示するには、もう一度実行ショーPROCESSLIST、例特に慎重に分析
そして最後に、このSQLを実行し、そしてtmpのテーブルに一時テーブルにコピーされた、本当の犯人を発見した、ビジネスが何であるかを知っているだろう、このSQLを見つけ、元は「異常通知サービス」タイムタスクは一時的な後ろに、ありますその後、緊急時の最適化に特化ビジネスを行う、サイトへのアクセスを復元するには、この事業を停止します。
締結
それは夜にあるため、システムの最初の日に起因するフィールドがアイドル状態のインデックス化テーブルに誰かを追加し、オンライン版の前日である、システムを使用するためにスタッフが開いていないされている次の日に問題を見つけられませんでした。
重要なステップ：
主に行ってショーPROCESSLISTは、すべてのオペレーティング・テーブルがスレッドを参照
、これは一時的な結果セットはtmp_table_sizeより大きいですので、tmpのテーブルに状態状態のコピーで見つかったが、メモリを節約するために一時テーブルは、ディスクストレージからメモリに保存されています
ソリューション：
一時的にSQLサービス、緊急時の最適化SQLを停止しました。その他のMySQLの最適化手法は、このブログ記事を参照してください。https://blog.csdn.net/u012104435/article/details/50915604
リフレクション：
方向の上、調査、メイン右方向に投稿されました、間違った方向にも多いと全く方向軽微ではありません、私は次の出会いも同様の問題が解決されることを願って、非常に神経質と紆余曲折、調査プロセスを出しました。
