1>
問題の説明
グループクラッシュモジュールにおける顧客からのフィードバックは、システムが異常となり、システムがログインできません。
モジュールの閲覧モジュールを閉じた後、システムが問題を何度も繰り返し、正常に戻りました。
プロセス
ヘルプのトラブルシューティングの問題は、最適化モジュールは、SQLにパフォーマンスの問題に長いリードを照会中に発見された前記主に問題の原因図SQLフラグメントの下部：
上記のSQL workflowtyeのプロセステーブルに格納されている場合、実際句チャーコンテンツタイプ、障害の原因となる比較インデックスを関連分野の二つの異なるタイプint型のものであり、。
SQLパフォーマンスのcontenフィールド型がintの後に正常に戻っている変更します。
フィールドタイプは、初期の設計テーブルで設定されているのと同じタイプを関連付けるために必要とされるべきです。それ以外の場合は深刻なパフォーマンスの問題が発生します、最新の変更の難易度が大きくなります。
2>
問題の説明
顧客回線との圧力試験中に大量のデータのインタフェースSQLクエリのパフォーマンスは、顧客の要件を満たすことができない見つけ、最適化を変換する必要があります
プロセス
次のようにメインのかかる仕分けページ付けでSQLクエリロジックの後、SQL流線ロジックは次のとおりです。
次のように最適化のロードマップは、次のとおりです。
これは、SQLタブ+最初のロジックを書いて、並べ替え、および主キーテーブルを返すためにCREATEDATE CREATETIMEソートの必要性を使用する場合には、他のフィールドに付帯情報を照会するに似ています
あなたは、インデックスを使用することができますが、このロジックは、より信頼性の後、再びページングする場合は特に、最も効率的ではありませんが、オフセットが増加すると、メモリ内にさらに多くのデータを取得する必要が、クエリがより多くの年かかります。
SQL、requestidとCREATEDATEを書いている第2の方法は、CREATETIMEフィールドは、ソートやページングの際に、インデックスを持って、あなただけの、（MySQLのインデックスは概念をカバー）検索インデックスを完了する必要があります
唯一の内側は、外部テーブルとの結合ページング後requestid値を取得、クエリ速度が大幅に改善され、クエリ効率によってページング後に有意に低下しません。
3>
問題の説明
ヘルプのトラブルシューティングデータベースの問題への顧客データベース環境CPUの警告メッセージが表示されます。
プロセス
スローログで分析し、最適化されたデータベースの全体的なパフォーマンスの分析。
ここに私たちのプログラムのロジックを引用した一般的な問題があります：
SQL断片の一環として、
SQLコードは、比較的大きな結び目のケースで存在するデータをフィルタリングするためのロジックを使用して慣れている多くの開発者を発見したが、MySQLで、でも結果セットのインデックスフィールドの存在ではなく、最高のパフォーマンスが存在します
検索速度が内部はるかに少ないが存在するハッシュ結合の参加、および過度の使用は、SQL実行計画を存在簡単に比較的多くのロジックは、内側、異常につながる直接結合し、簡素化。
私たちは、優先順位のロジックをお勧めします：参加>>で存在します