ストレージ構成指数
L BツリーとB +ツリーの特性との違い
* ツリーの高さは、一般的にある、2-4、この高さを直接木の高さに影響 IOの数は、読み取りおよび書き込みを。
* 3つのツリーがある場合はツリー構造は--- 4件の支持データが十Tに達する可能性がある場合---裏付けるデータは、20Gに達する可能性があり
* BツリーとB +ツリーの最大の違いはあるかどうかストアへのデータの問題は、非リーフノードいます。Bツリーの非リーフノードとリーフノードは、データを記憶されています。そして、 B +ツリーのリーフノードのみがデータを格納し、データは1行に格納され、これらは、すべてのデータ・ポインタ、すなわち配列されています。
リットルの非クラスタ化インデックス
* リーフノードへのポインタのみデータラインを格納要するに、データとインデックスは、一緒にされ、非クラスタ化インデックスはありません。
* 主キーのインデックスとセカンダリインデックスポインタ値が格納されてい
Lクラスタ化インデックス（ InnoDBテーブル）
* 主キーインデックスデータとインデックスが一緒にいると言うことですリーフノード店の（クラスタ化インデックス）のデータライン、これはクラスタ化インデックスです。
* セカンダリインデックスは、プライマリキーの値を格納します
* 主キーがない場合は、一意のインデックスの使用ビルドクラスタ化インデックスを、一意のインデックスが存在しない場合、 MySQLは一定のルールに従ってクラスタ化インデックスを作成します。
インデックスの使用を注意してください
複合インデックスを作成するために、Lトライ（コンポジットインデックスは、実際にインデックスのグループを作成するために私たちを助けるために、最も左接頭原理に従ってデフォルト設定されます）
コンビネーションインデックス（ ID、名前、性別）
最も左接頭原則リットルインデックス
クエリに列だけでなく、インデックスの使用を包含する：Lインデックスがカバー
ビューのMySQLのパフォーマンスの実行計画を説明
入門
リットルのMySQLが提供するEXPLAINコマンドを、それができるために、SELECT文を解析し、出力の詳細は、最適化の目標と開発者のための実行]を選択します。
リットル 使用して、SQL文がインデックスには使用していない参照して、実行計画にこれらのSQL文を表示するには、このコマンドの説明説明コマンドで見ることができる全表スキャンを行っていません。
リットル ができ、コストベースのオプティマイザのMySQLのコマンド深い理解を説明するには、あなたも多くの詳細は、アクセスポリシーは戦略がオプティマイザを採用することが期待されているSQL文を実行するときだけでなく、考慮され、最適化することができる得ることができます。
lは、コマンドの使用方法は非常に簡単ですEXPLAIN、プラスSELECT文では、例えば前に説明します。
説明ユーザから選択*を
パラメータ説明
expain情報の10アウトを持っている、すなわち、ID、SELECT_TYPE、表、タイプ、possible_keysは、キーは、key_lenに、REFは、行は、エクストラ、これらのフィールドは、以下に説明されています。
L番号:.各SELECT SELECTクエリの識別子を自動的に固有の識別子が割り当てられます。
Lの SELECT_TYPE：SELECTタイプのクエリ。
Lテーブル：テーブルクエリ
リットルパーティション：パーティションの試合
L タイプの：参加型
Lのpossible_keys：クエリは、インデックスを選択することができます
L キー：インデックスを照会する正確な使用。
L REF：どのフィールド定数またはキーと一緒に使用されています
Lの 行：このクエリは、走査線の総数が、これは推定値で表示します。
リットルをろ過：これを濾過し、クエリデータの割合を示します
リットルの余分：追加情報
SELECT_TYPE列説明
Lの SIMPLE、このクエリは、クエリまたはサブクエリUNIONが含まれていないことを示しています
L PRIMARYは、クエリを示すことは、最も外側のクエリであります
L UNIONは、クエリを示し、第2またはUNIONの後続の問合せであります
L DEPENDENT UNION、第二以降のUNIONクエリ、クエリの外側に応じ
L UNION結果、UNION結果
L SUBQUERY、最初のサブクエリSELECT
L DEPENDENT SUBQUERY：最初のサブクエリのSELECTクエリの外側に応じサブクエリ外部クエリの結果に依存しています。
1.1 型カラムの説明の
一般的に言えば、以下のように、パフォーマンスのタイプ関係の異なる種類は次のとおりです。
ALL <指数<〜index_merge範囲<REF <でeq_ref <constの<システム
| タイプ |
意味 |
| システム |
テーブルのみ一行 |
| CONST |
比べ最大で1つの行、ジェネリックまたは一意の主キーのインデックスの表マッチ |
| でeq_ref |
各時間は、唯一使用=によって特徴付けシステム、CONST最良の種類に加えて、あるテーブルの行の前の行と結合テーブルを読み、そしてすべてのインデックスの部分を結合に関与し、インデックスがプライマリ・キーであるか、または空のユニークキーインデックス |
| REF |
時間が少数の行と一致した場合、それは一種優れている、または= <=>使用は、被覆し又は残してもよい非プライマリキーのインデックスまたは一意キー |
| 全文 |
全文検索 |
| ref_or_null |
refに似ていますが、NULLを含みます |
| index_merge |
これは、インデックスマージ最適化（労働組合との交点、労働組合との交点を含む）ことを示しているが、クロステーブルとフルテキストインデックスが含まれていません。 コスト推定値が良好正常範囲よりもする場合は、この複雑な組み合わせ現在の理解は、次いで、（単一テーブル索引スキャン範囲であります |
| unique_subquery |
サブクエリ内でフォーム「を選択しunique_key_column」サブクエリの交換に（選択...）の値です。 PS：だから必ずしもクエリのサブ節では非効率的です！ |
| index_subquery |
以上のように、しかし、「選択non_unique_key_column」に息子のような形を置き換えるクエリ |
| 範囲 |
一定の値の範囲 |
| 指数 |
取得した時間インデックスツリーからクエリがインデックス付けされたカバーは、すなわち、すべての利用可能なデータ（追加インデックスを使用して持っています）。 。B指数インデックスから（NOインデックスを使用して）、フルテーブルスキャンラインデータを見つけるため。 。Cの場合エキストラ指数とする場合、その後、キー手段を見つけるためにインデックスを使用することです使って同時を使用します。 D。もし単独で表示され、それを見つけるための行を置き換えるために、読み取り率で読み取るのではなく、 |
| すべて |
全表スキャン |
MySQLのスロークエリのパフォーマンスの最適化
パフォーマンスの最適化のアイデア
1.まず、必要がSQLクエリ言語の長い期間を取得するために、すべてのクエリをスロークエリを使用する
実行計画を表示する説明2. SQLを。
3.ショープロフィールは、パフォーマンスの問題SQLの実行を確認してください。
入門
リットル 、データベースクエリの速度は、データベースのために、我々だけでなく、最適化するには、プロジェクトのパフォーマンスに影響を与える主な要因である SQL、より重要なのは、しなければならない最初の最適化に必要見つけ SQLを。
リットルのMySQLデータベースを持っている「スロークエリログ」機能をするために使用された記録クエリ時間を設定値超え SQL大幅に私たちを助ける、問題の核心にすばやく移動右薬を処方するためには、。
*クエリが遅いと考えられているどのくらいの時間については、事業の各項目は異なる要件があります。
* 従来のエンタープライズ・ソフトウェアは、クエリ時間一定の値を超えることができますが、インターネット上またはシェレメチェボプロジェクトサイトでこの標準、それがいると推定されたバグ、さらには機能的欠陥にアップグレードすることができます。
リットルのMySQLのスロークエリログ機能は、デフォルトでは手動で開く必要がオフになっています。
スロークエリ機能をオンにします
リットルの オープンスロークエリ機能するかどうかをチェック
「％slow_クエリ％」のような変数を表示。
SHOW変数はLIKE」長いクエリTI私％
パラメータ：
* Slow_query_log：スロークエリログを開くかどうかを、 ONにON、OFFがオフになっている、あなたがオフの場合はオンにすることができます。
*ログ・スロークエリ：レガシー（バージョン5.6以下）のMySQLデータベーススロークエリログ保存パス。このパラメータを設定することはできません、システムはデフォルトのファイルhost_nameの-slow.logにデフォルト設定されます
* SLOW-クエリログ・ファイル：新バージョン（ 5.6以降）、MySQLデータベーススロークエリログ保存パス。このパラメータを設定することはできません、システムはデフォルトのファイルhost_nameの-slow.logにデフォルト設定されます
* Long_query_time ：スロークエリのしきい値、クエリ時間が秒をログに記録する、より多く設定されたしきい値を超えています。
リットル スロークエリ機能の一時的なターン
で MySQLの設定SQL文を実行しますが、再起動した場合、その後、MySQLは失敗します
グローバルslow_query_log = ONを設定します。
set global long_query_time = 1;
l 永久开启慢查询功能
修改/etc/my.cnf配置文件，重启 MySQL, 这种永久生效.
1 [mysqld] 2 slow_query_log = ON 3 slow_query_log_file = /var/log/mysql/slow.log 4 long_query_time = 1
l 慢日志格式
格式说明：
* 第一行,SQL查询执行的时间
* 第二行,执行SQL查询的连接信息，用户和连接IP
* 第三行,记录了一些我们比较有用的信息，如下解析
Query_time,这条SQL执行的时间,越长则越慢
Lock_time,在MySQL服务器阶段(不是在存储引擎阶段)等待表锁时间
Rows_sent,查询返回的行数
Rows_examined,查询检查的行数，越长就当然越费时间
* 第四行,设置时间戳，没有实际意义，只是和第一行对应执行时间。
* 第五行及后面所有行（第二个# Time:之前）,执行的sql语句记录信息，因为sql可能会很长。