スロークエリとは何ですか？
スロークエリ定義と役割
スロークエリログには、定義、スロークエリログにより、ログ時間しきい値long_query_timeパラメータ設定よりも多くの実行されたすべてのSQL文を記録MYSQLを参照してください。ログには、最適化されたSQL文のための良い助けをもたらすことができます。デフォルトでは、スロークエリログには、あなたが最初のスロークエリログ機能をオンにする必要がありますスロークエリログ機能を使用するために、無効になっています。
遅いクエリを開始します
常用配置
slow_query_logスタートストップ技術スロークエリログ
slow_query_log_fileスロークエリログは、ストレージ・パスとファイル指定（デフォルトのデータファイルと一緒に入れて）して
long_query_time指定されたレコードスロークエリログのSQLの実行時間が値を切断された（単位：秒、デフォルトでは10秒）
レコードはインデックスを使用していないかどうかをlog_queries_not_using_indexes SQL
ローカルlog_outputログストレージ[TABLE] [FILE] [FILE、TABLE]
録音は、資格のあるSQLました
質問
データ変更ステートメント
SQLは、あまりにもロールバックされました
スロークエリログの解析
一般的に使用されるスロークエリログ解析ツール（mysqldumpslow）
クエリ他の同一のSQLに加え要約、および出力分析で指定されたパラメータに応じて結果の順序。
文法
mysqldumpslow -SR -t 10スローmysql.log
-sオーダー（C、T、L、R、で、ら、AR）
C：の合計数
T：総時間
L：ロック時間
R：総データ線
で、ら、AR：T、L、R [例えば平均：=総時間/合計数で】
結果として出力を指定するために撮影した日の-tトップフロント
例：
mysqldumpslow.pl -st -t 10 D：\デスクトップ2EKGEE5-slow.log
一般的な最適化
サーバーハードウェア
MySQLサーバの最適化
SQLの最適化そのもの
アンチパラダイム設計の最適化
索引チューニング
アンチパラダイムデザイン
抗パラダイムデザインとは何ですか？
アンチ正規化は、の面でパラダイムのためであります
いわゆる抗正規化は、適切なデータベース設計パラダイムを読み、検討する必要があり、パフォーマンスと効率を得る必要がある要件に違反して得られました
それは言い換えれば、抗正規化は、時間のためにスペースを使用することで、冗長性の少量を許可しています
三つの形式
データベース設計の最初の大きなパラダイム
データベーステーブル内のすべてのフィールドは、単一の属性を持ちます
コラム単一の属性は、基本データ型で構成されています
テーブルは、単純な2次元テーブルを設計されています
データベース設計の第二の大きなパラダイム
それだけで自然キー、すなわちテーブルを有するテーブルが主キーの一部にのみ依存非プライマリキー列の第二のパラダイム存在を満たすことができない必要
注文番号と製品IDなしの直接リンク
変更した後 - >
データベース設計の第三のパラダイム
各属性はFeifeiの主要部分は、いずれも伝送に依存している意味も自然キーに依存して、すなわち、主キーの依存性のために、非プライマリ・キーに沿って送信される第2のパラダイムに基づいて
顧客管理に関連した番号と注文番号
顧客名と注文番号の管理に関連しました
関連する顧客番号と顧客名
この列は、顧客テーブルに置かれ、顧客の名前を削除します
どのような指標がありますか？
MySQLはインデックスの公式な定義です：ヘルプのMySQLへのインデックス（指数）は、効率的にデータのデータ構造を取得します。
インデックスは、自然の中で取得できます。インデックスは、データ構造です。
最も単純な指標
少し複雑インデックス
インデックスのMySQL
上記は、データテーブルで、2〜7のレコードの合計、左端は、データレコードの物理アドレスであります
MySQLのInnoDBのデフォルトのストレージエンジンのみ明示的な支援Bツリー（B +ツリーは技術的である）インデックス
インデックスの分類
共通のインデックス：つまりは、単一の列のインデックスが含まれ、テーブルには、複数の独立したインデックスを持つことができます
唯一のインデックス：インデックス列の値は一意であるが、自由な値を許可する必要があります
複合インデックス：インデックスは、複数の列を含みます
インデックスを作成します
MYTABLE ON [UNIQUE] INDEX INDEXNAME（ColumnNameの（長さ））を作成します。
ALTER TABLE表名ADD [UNIQUE] INDEX [INDEXNAME] ON（ColumnNameの（長さ））
ビューのインデックス
TABLE_NAME FROM SHOWのINDEX
インデックスの削除
DROP INDEX [INDEXNAME] ON MYTABLE
実施計画
どのような実行計画？
使用彼らはあなたのMySQLがSQL文です処理する方法を知っているので、実行するキーワード缶シミュレートSQLクエリオプティマイザを説明します。クエリまたはテーブル構造におけるパフォーマンスのボトルネックの分析
文法
+ SQL文を説明
実施計画の役割
読み上げ順序テーブル
データは操作の操作タイプを読み取ります
どのインデックスを使用することができます
どのインデックスが実際に使用されています
テーブル間の参照
どのように多くの行のクエリオプティマイザの各テーブル
情報は、実施計画に含まれています
実施計画-ID
実施計画-select_type
実施計画-table
データは、テーブルの行を表示し、その上に
実施計画の型
タイプは、アクセスの種類は、より重要な指標であることを示し、最高から最悪の結果の値は以下のとおりです。
システム> constの>でeq_ref> ref>を全文> ref_or_null> index_merge> unique_subquery> index_subquery>範囲>インデックス> ALL
私たちは覚えておく必要があります
システム> constの>でeq_ref>参照>範囲>インデックス> ALL
実施計画-key_len
key_lenにインデックスが使用されるバイトの数を示します
この値によると、すべてのインデックスフィールドがクエリで使用されているかどうかを判断するためにインデックスの使用状況、特に複合インデックスを決定することができます。
文字エンコーディングとのcharとvarcharも密接にリンクされています、
LATIN1 1バイト、2バイトGBK、UTF8は、3つのバイトを占めます。（異なる文字エンコーディングは、ストレージスペースを取ります）
インデックスの最適化戦略
ポリシーの完全な値と一致するようにしてください。1.
EXPLAIN
スタッフSELECT * FROM WHERE NAME = '7月';
EXPLAIN
スタッフSELECT * FROM WHERE NAME = '7月' AND年齢= 25;
EXPLAIN
スタッフSELECT * FROM WHERE NAME = '7月' AND年齢= 25とPOSを= 'DEV';
2.最善の戦略左接頭辞ルール
インデックス複数の列場合は、最も左のプレフィックスは、法律を遵守しています。これは、最初の最前線に左端からクエリを参照し、インデックス内のインデックス列をスキップしません。
3.戦略は、インデックス付きの列に何もしません。
ない何でもコラム（計算、関数（）自動または手動型変換）指標を行い、インデックスがステアリング全表スキャンの失敗につながります
スタッフWHEREleft（NAME、4）= '7月' SELECT * FROMをEXPLAIN。
4.ポリシー条件の範囲は、最終的に置きます
ストレージエンジンは、範囲の条件の右側の列にインデックスを使用することはできません
インデックスを覆って使用する戦略に試してみてください5.
選択を減らすためにカバーするインデックス（指数のみアクセスクエリ（インデックス列と一貫性のあるクエリー列））を使用してみてください*
6.戦略も使用に等しくありません
インデックスは、全表スキャンにつながるときのmysql（！=または<>）は、使用中に等しくない場合は使用できません。
ポリシー7.Null /影響力はありません
インデックスのノートヌル/にnotnullに影響を与える可能性があります
クエリは慎重な戦略である必要があり8.Like
開始したいとワイルドカード（「％ABC ...」）MySQLの故障インデックステーブルスキャン操作が完成してしまいます
9.ポリシー文字型の引用符
単一引用符インデックスのない文字列の失敗
UNION効率的な変動戦略10.OR
私のお気に入りの試合の完全な値、遵守するための最も左のプレフィックス。
真ん中の弟が壊れてすることができない、ビッグブラザーに率先して死ぬことはできません。
以下、計算列のインデックス、フルレンジの後に障害が発生。
LIKE割合書き込み右端の、カバーするインデックスは*書き込みません。
等しくないNULLまたは、インパクト指標に注意を払うがあります。
VARCHARの引用符は、SQLの最適化にはコツがあり、紛失することはできません。
