序文
この記事では、データベースのMySQLで、主にリレーショナル・データを目的としています。
簡潔に次の基本的な概念を整理し、その後拡大し、クエリのこれら二つのフェーズのサブ最適化を作成MYSQL。
基本的な概念の1はじめに
1.1論理アーキテクチャ
- 第1層：クライアント接続サービス、実行によって送信されるSQL命令による
- 第二層：サーバーの解析と最適化SQLは、最終的な実装計画を生成し、実行します
- 第三層：ストレージエンジンは、データの保存と検索のために責任があります
1.2ロック
共有ロック（読み取りロック）と排他ロック（書き込みロック） - ロック機構によって解決並行処理のシナリオへのデータベース。読み取りロックがブロックされていない、複数のクライアントが同時に同じリソースから読み取ることができます。書き込みロックは排他的であり、他の読み取りと書き込みロックをブロックします。単純に楽観と悲観的ロックの下に置きます。
- オプティミスティック・ロックバージョン番号とタイムスタンプによって達成一般的にデータ競争力の弱いシーンのために使用され、より少ない読み書き、。
- ペシミスティック・ロック通常、データの激しい競争のシーンのために使用さは、各操作は、データをロックします。
データをロックするには、に対処するため、特定のロック戦略が必要です。
- 表ロック、テーブル全体をロックし、最小のオーバーヘッドが、競争がロックを強化します。
- 行ロック、行レベルのロック、最も高価な、しかし同時実行のサポートの最大の程度。
しかし、ストレージエンジンMySQLの実際の実装は、通常、マルチバージョン同時実行制御（MVCC）を達成するために、単純な行レベルのロッキングではありません。MVCCは、ロック操作は、ほとんどの場合、低コストで回避され、行レベルロックの変異体です。MVCCスナップショットは、データを保存する時にポイントを介して達成されます。
1.3トランザクション
トランザクションの保証業務の原子セット、どちらかすべて成功するか、すべて失敗します。それはロールバックする前に、すべての操作を失敗するはずです。明示的にトランザクションとして、各クエリを起動しない場合、MySQL自動は、提出します。
分離レベルは、可視およびトランザクション内のトランザクション間でトランザクションの変更を制御します。一般的な4つの分離レベル：
- 非コミット読み取り（READ UNCOMMITTED）は、また、目に見えるその他の事項に提出していない場合でも、トランザクションを変更します。トランザクションは、ダーティリードが得られ、コミットされていないデータを読み取ることがあります。
- コミット読み取りトランザクションの開始時に、唯一の企業が行うための修正を提出してきた見て、（読み取りコミット）。コミットされていないトランザクションの前に、他のトランザクションに加えられた変更は表示されません。また、非反復可能読み取りとして知られている、私は何度も同じトランザクションが異なる可能性が同じレコードを読み取ります。
- 反復可能読み取り、同じトランザクション内で同じレコードを複数回の結果の結果を読み、同じ時間（RepeatTable読み取りを）。
- シリアライズ（直列化）、分離の最高レベルは、トランザクションシリアル実行を強制します。
1.4ストレージエンジン
InnoDBエンジン、最も重要で最も広く使われているストレージエンジン。高パフォーマンスと自動クラッシュリカバリの特性を有する、短期の多数のトランザクションを処理するように設計されています。
トランザクションと行レベルのロックをサポートしていないのMyISAMエンジンは、セキュリティがクラッシュ後に復元することはできません。
2最適化を作成します。
2.1スキーマのデータ型と最適化
整数
TINYINT、SMALLINT、MEDIUMINT、INT、のBigInt 8,16,24,32,64ビットが記憶空間を使用して格納されています。負の数値を使用することを許可されていない場合は符号なし、あなたはラインの倍増に正の数を作ることができます。
リアル
- フロート、ダブル、おおよその浮動小数点演算をサポートしています。
- 小数、小数の精度を格納します。
弦
- VARCHAR、可変長文字列を格納。これは、1つのまたは2の追加レコード長のバイト列が必要です。
- チャーは、例えばMD5値として固定長の文字列を格納するために、固定長。
- ブロブ、データおよびデザインの多くを保存するためのテキスト。それぞれ、バイナリ文字を介して。
タイムタイプ
- 日時は、値が、8バイトの広い範囲を保存します。
- タイムスタンプは、同じUNIXタイムスタンプ、4つのバイトをお勧めします。
最適化のヒントポイント
- 対応するデータ型を利用すること。たとえば、IP保存不可欠で、文字列型で時間保存しないでください。
- 小さいデータ型を選択してください。TINYINTはできないのInt。
- ID列（識別子列）は、より多くのスペースを取り、そして遅く整数よりも速度を計算し、文字列型が推奨されていない、整数を使用することをお勧めします。
- ORMは、一般的に大規模なVARCHARタイプ、インデックス不合理な使用やその他の問題を使用して、データの種類に焦点を当てていませんが、自動的に生成されたスキーマをお勧めしません。
- 実シーンミックスパラダイムとカウンターパラダイム。冗長高いクエリ効率、低挿入更新効率、低挿入冗長高い更新効率、低クエリ効率。
- 完全に独立した要約\キャッシュテーブルを作成し、データを生成するタイミングは、ユーザーが操作のために長い時間がかかります。高精度要件の概要操作では、高速なクエリの目的を達成するために、最新の結果+の結果の履歴レコードを使用することができます。
- 使用する新しいテーブルの目的に影響を与えずにデータ移行、アップグレードプロセステーブルは、履歴データの保存に、元のテーブルを変更することで、テーブル名をシャドー・テーブルを使用することができます。
2.2インデックス
1つ以上の列を備えたインデックス値。MySQLは唯一の接頭辞を最も効率的に使用することは、インデックスの列を残しました。利点のインデックス：
- データクエリのスキャンの量を減らし
- 避け順序とテーブルゼロ
- 順序はランダムIO IO（IO効率がランダムな順序IOよりも高い）になります
Bツリー
インデックスの最も使用されているタイプ。Bツリー・データ構造は、（各葉ノードは、それによってリーフノードのトラバースを容易、次のリーフノードへのポインタを含む）データを格納するのに用いられます。全キー、キーレンジ、キープレフィックスのルックアップ、サポートソートに適用B-Treeインデックス。
Bツリー索引の制限：
- それは左端の列インデックスがクエリに始めに従わない場合は、インデックスを使用することはできません。
- あなたは、インデックスの列をスキップすることはできません。あなたが最初の列と3列目のインデックスを使用する場合は、インデックスのみの最初の列を使用することができます。
- 範囲クエリのクエリがある場合は、その右側にあるすべての列が最適化クエリにインデックスを使用することはできません。
ハッシュインデックス
すべての列のインデックスの唯一の完全一致、クエリが有効です。すべてのストレージエンジンは、ハッシュコードインデックス列を計算するインデックスに格納されている全てのハッシュインデックス、ハッシュコード、および各データ線へのポインタを格納します。
ハッシュインデックスの制限：
- これは、ソートに使用することはできません
- これは、部分一致をサポートしていません。
- 唯一同等のクエリをサポートする=、IN（）、<サポートしていません>
最適化のヒントポイント
- 注該当する各指標の範囲と限界という。
- 列インデックスは、パラメータの発現または機能は、障害の一部である場合。
- 特に長い文字列の接頭辞インデックスの選択性指数を有する適切なプレフィックス長を選択するために使用されてもよいです。
- 複数列のインデックスを使用する場合、AND及びOR文法によって接続することができます。
- 重複率は、（A、B）のように、必要ではなく、（A）が繰り返されます。
- インデックスは、クエリの構文によって条件どこクエリおよびグループに特に有効である場合。
- 最後のクエリの条件にお問い合わせの範囲、右のインデックスの故障に起因する問題を防止するためのクエリスコープ。
- インデックスは長すぎる、とインデックス列がnullであってはならない文字列を選択するのが最善ではありません。
3最適化されたクエリ
問い合わせ3.1の品質の三つの重要な指標
- 応答時間（サービス時間、キュー時間）
- 走査線
- リターンライン
3.2クエリの最適化のポイント
- 避けては、そのような使用として、無関係の列を照会し、すべての列を返すように*を選択します。
- クエリに依存しないのは避けて行
- セグメンテーションクエリ。サーバー上の大きな圧力のタスクは、長い時間をで分解し、複数の実行中にします。削除10に千個のデータ点は、一時停止の実施期間が終了した後10回、毎回実行し、続行することができます。プロセス・サーバーのリソースを他のタスクに解放することができます。
- クエリに関連した分解。最初のマルチテーブル、クエリ、クエリに関連付けられた複数の単一テーブルのクエリに分解する。ロック競合を減らすことができ、クエリ自体のクエリ効率が比較的高いです。MySQLの接続と切断操作が軽量であるため、クエリは効率が得られ、何回かに分割されていないので。
- 行数の合計数が、カウントを使用するので、統計のみをカウントすることができ、操作がnullのカラムが、ないことに注意してください（*）。
- 高い充填効率の識別に応じて、カラムによるグループは、パケットの結果は、列グループ化列を越えて移動するべきです。
- リレーショナルクエリに関連する遅延は、ベースの再関連付けを自分の検索条件を絞り込むために照会することができます。
- ページの最適化を制限します。走査は、インデックスに応じて被覆することができ、クエリ他の列は、インデックス列に応じて、それ自体に関連します。として
SELECT id, NAME, ageWHERE student s1INNER JOIN ( SELECT id FROM student ORDER BY age LIMIT 50,5) AS s2 ON s1.id = s2.id- 事業は、連合のすべてのより効率的な使用を推奨しなければならない場合連合は、体重をデフォルトに問い合わせます
サプリメント
偉大な神から - アンディ
- テーブル構造タイプフィールドタイプおよび条件は、MySQLは、障害のパラメータの関数として指数で得られ、自動的に転送機能を追加した、矛盾しています。
2.likeインデックスを打つことができませんでした％で始まり、前のセクションでのクエリを入力していません。
- バージョン5.7の2つの新機能を補完します：
生成されたカラムは、カラムを与えるために他の列のデータベースから算出されます
CREATE TABLE triangle (sidea DOUBLE, sideb DOUBLE, area DOUBLE AS (sidea * sideb / 2));insert into triangle(sidea, sideb) values(3, 4);select * from triangle;+-------+-------+------+| sidea | sideb | area |+-------+-------+------+| 3 | 4 | 6 |+-------+-------+------+サポートJSON形式のデータは、および提供する組み込み関数
CREATE TABLE json_test (name JSON);INSERT INTO json_test VALUES('{"name1": "value1", "name2": "value2"}');SELECT * FROM json_test WHERE JSON_CONTAINS(name, '$.name1');JVMの専門家 - アップ
使用が心配パフォーマンス分析で説明
EXPLAIN SELECT settleId FROM Settle WHERE settleId = "3679"
- select_type，有几种值：simple（表示简单的 select，没有 union 和子查询），primary（有子查询，最外面的 select 查询就是 primary），union（union 中的第二个或随后的 select 查询，不依赖外部查询结果），dependent union（union 中的第二个或随后的 select 查询，依赖外部查询结果）
- type，有几种值：system（表仅有一行（= 系统表），这是 const 连接类型的一个特例），const（常量查询）, ref(非唯一索引访问，只有普通索引)，eq_ref（使用唯一索引或组件查询），all（全表查询），index（根据索引查询全表），range（范围查询）
- possible_keys: 表中可能帮助查询的索引
- key，选择使用的索引
- key_len，使用的索引长度
- rows，扫描的行数，越大越不好
- extra，有几种值：Only index（信息从索引中检索出，比扫描表快），where used（使用 where 限制），Using filesort （可能在内存或磁盘排序），Using temporary（对查询结果排序时使用临时表）
（完）
