もうすぐ終わりに近づいて4ヶ月間のインターンシップは、実際の業務データのラインが最大のパフォーマンスの向上を取得するには、SQLを使用して処理されたときに百万HIVEテーブルデータの最適化の面です。知識のこの種で。
全表スキャンと索引スキャン
データベースにおいて、非テーブルのクエリのインデックスは、一般に、全表スキャンと呼ばれます。全表スキャンは、データベース・サーバ返さ与えられた条件に一致するすべてのレコードまで、検索リストの各レコードを処理するために使用されます。
インデックスは、ディレクトリデータベースを指しているデータベーステーブル内の1つの以上の列の設定値がソートされ、インデックス固有の情報は、データベーステーブルを迅速にアクセスすることができます。あなたは彼または彼女を見つけるために、スタッフが特定の名前をしたい場合は、テーブル内のすべての行を検索と比較して、インデックスがより速く情報を取得するのに役立ちます。インデックスの主な目的は、缶のヘルプサーチャーは、できるだけ早くレコードIDの制限に沿った情報の補助データ構造を見つけることを、検索データテーブル方式をスピードアップすることです。
要するに、全表スキャン、データ結果を表示するには、テーブル内のすべてのデータの上に行くべき手段は、インデックスがスキャンだけあなたが結果を得ることができ、データの一部をスキャンする必要がある指標です。
基本的には。データがテーブル全体の大半を占めて取得するには、全表スキャンの方が適切である（インデックスに1が第二のデータの追加や削除、およびに助長されていません、インデックスもオーバーヘッドが必要ですが、不適切なシステムクエリのパフォーマンスの確立に影響を与える場合）;のみ、テーブル全体の場合小さな部分は、それは通常、より良いインデックス・スキャンです。
インデックスに関するいくつかの少しの知識：
1.インデックスは何ですか
（大量のデータに適用可能な）ディレクトリ上記辞書文字：指標のような、ディレクトリデータベースを参照します
インデックスの2長所と短所
長所：高速なクエリの速度の
短所：スロー追加や削除、データベースは、インデックスファイルを維持するために同期化するように、とても遅いです
3.インデックスは何ですか
通常の主キーユニークな組み合わせ
4.なぜ速いインデックス検索
インデックス構造：B +ツリー
通常、どのような状況下でインデックス化5.
1.主キーは自動的に一意のインデックス作成
インデックス作成する必要があり、クエリ条件フィールドとして頻繁2.
他のフィールド、外部キー関係のインデックスに関連付けられている3.照会テーブル
の選択4.速度/併用指数、より費用対効果の組み合わせ指数を高
5.クエリのソートフィールドは、アクセスのインデックスによるソートフィールドが大幅のソートの速度が向上します場合は
6または統計クエリパケットフィールドを。
7.フィルタ選択フィールド条件は、選択されたインデックス付きのに適してい
6.ノウハウ無用使用率
SQLクエリの実行計画を説明することで、主に使用されているキーのインデックスを表示するには
7.複合インデックスは、それを使用し、それが注文され
使用済み整然とした
8.インデックスは、どのような状況下で失敗するでしょうか？（第二部のSQLの最適化に関連します）
1.like
2.like「％123パーセントではなく、フロント％+
3にキーワードを使用するか、ヌル,! =
4 ....
インデキシング
まず、インデックスデータベースの原則
操作に動作テーブルのクエリの多数または付加および欠失の大きな数を決定1。
2.特定のクエリをインデックスヘルプを試してみてください。頻繁にwhere句に表示されるフィールドにインデックスを付ける、あなたのSQL文を確認してください。
3.さらに、システムのパフォーマンスを向上させるために複合インデックスを確立するようにしてください。複合インデックスは、ディスク・スペースを占有しながら、複合インデックスは、より多く消費されます変更します。
4.小さなテーブルでは、インデックスは、パフォーマンスに影響を与える可能性があります
5.それは小さな値インデックスを持つフィールド避けるべきである（例えば性別など、唯一の男性と女性を。索引付けのための名前、通りまたは郵便番号がより適しています）。
インデックスデータとしてカラムの大きいタイプを選択する6.避け。
インデックスのA.mysql原則
データベースがないこれらのフィールドと併せて検討する必要があるインデックスにビルドクエリ、およびインデックスの要件と実際のデータベース・システムへの重要なレコードクエリメソッドを、あるクエリ指数は、原則のいくつかは、一般的な方法は以下の通りであります：
多くの場合、フィルタの分野で使用される1インデックス。
2.多くの場合、SQL GROUP BY文の中で、フィールド上のORDER BYインデックス。
このような少ない異なる値フィールドに性別フィールドとして3不要指数;
頻繁にアクセスされる行インデックスを回避するために4。
5. A結合列のインデックスに（主キー/外部キー）。
6.複合頻繁にアクセスされる複数列に確立指数が、複合インデックスの確立の順序は、使用頻度に応じて決定されるべきであることに留意されたいです。
7.非クラスタ化インデックスは、デフォルトによって確立された、しかし、のようなインデックス、クラスタ化された以下の例を検討する必要があります有限数のユニークなコラム（より小さい）を有する;クエリの広い範囲を、インデックスが完全に利用することができますテーブルスキャンI / 0の数を減らし、かつ効果的にテーブル全体を検索することは避けてください。もちろん、様々なクエリの分析と予測に基づいて構築することが合理的なインデックスは、データベース構造はまた、DBAの設計に依存します。
第二に、データベースのインデックス付きの文
1.PRIMARY KEY（主键索引）
MySQLの> ALTER TABLE `table_name`のADD PRIMARY KEY（` COLUMN`）
2.UNIQUE（唯一索引）
MySQLの> ALTER TABLE `table_name`のADD UNIQUE（` COLUMN`）
3.INDEX（普通索引）
MySQLの> ALTER TABLE `table_name`のADD INDEXのINDEX_NAME（` COLUMN`）
4.FULLTEXT（全文索引）
MySQLの> ALTER TABLE `table_name`のADD FULLTEXT（` COLUMN`）
5.多列索引
のMySQL> ALTER TABLE `table_name`のADD INDEX index_nameは（ `column1`、` column2`、 `column3`）
6. [削除]インデックス
table_nameでインデックスindex_nameのをドロップ
第二に、SQLの最適化のいくつかの方法
全体的な手順を最適化
A.まず、対応するSQL文と分析を見つけ、データベーススロークエリログ、SQLクエリの比較的低い効率にナビゲートを開きます
1.もし3つの標準的なパラダイムのテーブル設計は、標準である
（1）最初のパラダイム：保証アトミック（解決されない）
（2）第二のパラダイム：各テーブルの主キー
（3）第三のパラダイム（各列プライマリ・キーに関連する）
2.テーブル内のデータを表示するための冗長フィールドが多いされ、フィールドのデータ型が妥当である
テーブルの構成として代わりにCHARデータ型のvarchar型を使用して3、絶対値が文字を格納することができない
。4.回避をNULL値、ヌルのデフォルト値は、0の数値は、空の文字列を使用することができ、使用することができます
II。SQLステートメントは、規範かどうかを確認します
（1）キーワードを使用することは避けてください：いない中で、または、 =、<>、 ！* SELECTを使用することは避けてください
（2）サブクエリを回避しようと、ほとんどのサブクエリは、クエリに参加することができます
（3）または代わりに使用することができます代わりに達成するために労働組合を使用しての
（4）が存在して置き換えるために使用することができる代わりに使用されます
III。インデックスがために使用することができるかどうかを分析SQL
（1）、タイプがフルテーブルスキャンはないSQLクエリの実行プランは、複数の列に焦点を当てることで説明
インデックスが使用できるかどうか（2）外観は、主にインデックスを使用するキーを参照するために、
行における（3）外観走査線の数は大きくありません
説明します
mysqlのselect文と接続テーブルを処理するためにインデックスを使用する方法のショーを説明します。あなたはより良い指標を選択して、より最適化されたクエリを記述することができます。
使用は、それに加えて上のselect文の前に説明します。
以下のような：
選択姓、FIRST_NAME形態A、B a.id = b.idを説明
いくつかのトリックの最適化
1.クエリの最適化は、最初の場所と順番に関与列でインデックス作成を検討すべきで、全表スキャンを回避しようとしてください。
2.フィールドがヌル値に避けるべきであるwhere句で決定される、など、エンジンがインデックスとフルテーブルスキャンを使用して放棄します：
NUM TがNULLである場所からSELECT ID
を保証するために、0 NUMのデフォルト値を提供することができますテーブルのnum個の列の値がnullでない場合、このクエリ：
SELECT ID Tから= NUM 0
3. where句=または<>演算子、そうでない場合はエンジンがインデックスと全表スキャンを使用して放棄するには避けるべきです！ 。
：4は、接続または状態が、エンジンがインデックスとフルテーブルスキャンを使用して放棄する原因となる、などの句ここでは避けるべきである
NUM = NUM = 10 TからSELECT ID、または20である
：この照会可能性
からSELECT IDがNUM = 10 T WHERE
連合すべての
= 20上記IDからSELECT T NUM
：5.Inは注意しなくで使用されるべきであるが、それ以外の場合のようなフルテーブルスキャンにつながる
ここで、T（2、3）から上記IDでSELECT NUM
ため：連続値は、間に使用することができない
1と3の間SELECT上記IDからT WHERE NUM
6.クエリがスキャン完全なテーブルになり、次
のように「%% ABC」TからSELECT名ID
7.フィールドはエンジンがインデックスを使用してあきらめてしまいますこれ、where句式で動作するように避けるべきであると全表スキャン。例えば：
SELECT NUM ID T / 2 = 100がどこから
読むべき：
NUM = 100 * T 2つのここからSELECT ID
8.フィールドが機能するために避けるべきであるエンジンがインデックスを使用して放棄する原因となり、where句で操作しました全表スキャン。例えば：
サブストリング（名前、1,3）=「ABC」T IDからの選択-最初に名前ID ABCに
読むべきである：
「ABC％」名等TからSELECT ID
9節がない場合「=」は、機能は、算術演算を実行し、又は他の表現、またはシステムが正常にインデックス付けをすることができない左。
インデックスは複合インデックスがある場合、あなたはシステムを確保するために、最初のフィールドにインデックスを使用する必要があり、インデックスフィールドを使用しての条件として10は、条件として、そうでない場合は、インデックスが使用されないインデックスを使用し、すべきです可能な限りそのフィールドの順序は、順序インデックスと一致しているので。
11.クエリは、このような空のテーブル構造を作成する必要として、意味がありません。書いてはいけません：
tは1 = 0から#tをINTO SELECT COL1、COL2
このコードは、任意の結果セットを返しませんが、消費のシステムリソースは、変更する必要がありますこのように：
表は、（...）を作成し#T
：場所は良い選択と、多くの場合に存在する12
（BからSELECT NUM）はWHEREにAからSELECT NUM NUM
：次の文に置き換えた
SELECT NUMは、（SELECT Aから存在をNUM = B. 1 a.num）からWHERE
インデックスデータは、列を多数繰り返すと13ではないすべての有効なクエリインデックス、SQLクエリ最適化は、テーブル内のデータに基づいて行われる、SQLクエリはにインデックスを使用することはできません、テーブルなどは、性別に構築されたインデックスは、クエリの効率に影響を与えない場合でも、フィールドのセックス、男性、女性のほぼ半分ずつを持っています。
14.インデックスは不可能であり、対応するインデックスは確かに選択の効率を向上させることができ、また、挿入および更新の効率を低下させる
挿入または更新は、インデックスを再構築する時期が可能で、インデックスは慎重に検討する必要があるとして、どのようにビルドするには、場合であってもよいように。
あまりにも多くのあなたは、必要に応じてインデックス列を構築するために使用頻度の低いのいくつかを検討する必要がある場合は、インデックス番号テーブルは、最高の半年以上ではありません。
数値フィールドの15メイク使用、数値情報を含むフィールドのみが接続とクエリのパフォーマンスが低下キャラクターデザイン、可能ではなく、ストレージコストを増加させた場合。
一度だけ文字列内の各文字を比較することにより、クエリとの接続1を処理し、数値の比較のために、エンジンが十分にあるためです。
16.代わりチャーのVARCHARとしての使用、最初の可変長フィールド小さな記憶空間、記憶空間を節約することができるので、
クエリに続いて、検索効率の比較的小さな分野で明らかに高いです。
17. Doがより少ないとフィールドのいずれかを返さない、代わりに「*」のフィールドの特定のリストで、Tから選択*どこにも使用しません。
18.避けては作成頻繁に削除一時テーブルは、システムテーブルは、リソースの消費を削減します。
19. A一時テーブルが使用不可能ではありません、それは大きなテーブルまたはテーブル一般的に重複した参照データセット必要がある場合には、彼らは、例えば、特定のルーチンの適切な使用をより効率的にすることができます。しかし、1回限りのイベントのために、それは、エクスポートテーブルを使用するのが最適です。
20.場合、新しい一時テーブル一つ挿入大量のデータ、それは、ログの多くを回避するために、テーブルを作成するに代わりに選択を使用してもよい場合は
速度を上げるために、小さなデータ場合、システムリソーステーブルを容易にするために、SHOULDを挿入し、テーブルを作成します。
21.あなたは必ずすべての一時テーブルを明示する一時テーブルを使用する場合は、システム・テーブルに長い時間をロックを避けるために、テーブルをドロップし、ストアドプロシージャの終わりに最初の切捨て表を削除しました。
22.てみカーソルの効率が悪いが、カーソル操作10,000以上のラインならば、あなたは書き換え考慮しなければならないので、カーソルを使用しないようにします。
23.使用一時テーブルに基づく方法やメソッドの前にカーソルは、問題、通常、より効率的なセットベースの方法を解決するためにセットベースのソリューションを探す必要があります。
24.一時テーブル、カーソルは使用不可能ではありません。小さなデータセットに使用FAST_FORWARDカーソル特に、いくつかのテーブルを参照して必要なデータを得るためにある必要があり、よりよい他の進歩的な治療法よりも通常です。
結果セット内の速いカーソルの速度を用いて行う通常のルーチンより「全」を含みます。開発時間が許せば、カーソルベースの方法と優れている方法を参照しようとするベースのアプローチを設定することができます。
25.システムの同時実行性を向上させ、大規模なトランザクション操作を避けるようにしてください。
26.避けてはデータが大きすぎる場合、あなたが対応する需要が合理的である検討すべき、クライアントに大量のデータが返されました。
