MySQL面接復習2

1.ストレージエンジン
ストレージエンジン:データは異なる技術を採用してファイル(またはメモリ)に格納され、異なる技術は異なるストレージメカニズム、インデックス技術を持ち、異なる技術を選択することによって異なる機能を獲得し、それによって応用全体の機能を改善する.
1-1.INNODBストレージエンジン
紹介:
1.InnoDBは取引をサポートする.特徴:行レベルのロック設計、外部キーのサポート、非ロック読み込みなど
2.InnoDBはMVCCにより高い同時性を獲得し、SQL規格の4つの独立性レベルを実現した
3.InnoDBはデータを論理表空間に格納し、表は独立したibdファイルに格納される.
4.InnoDBは集約方式を採用し、各テーブルの記憶をプライマリ・キーの順に保存し、明示的にプライマリ・キーを指定しなければ、各行に6バイトのROWIDをプライマリ・キーとして生成する

アプリケーションシーン:高同時データ整合性、更新および削除操作が比較的多く、トランザクションロールバックおよびコミット

1-2.MyISAMストレージエンジン
紹介する
1.トランザクションと外部キー、テーブルロックと全文インデックスをサポートしない
2.記憶エンジンテーブルはMYD(記憶データ)とMYI(記憶インデックス)からなる

アプリケーションシーン:読み取り操作が多い

1-3.Memoryストレージエンジン
紹介する
1.データをメモリに保存し、一時記憶に適用し、デフォルトではハッシュインデックスを使用する
2.速度は非常に速いが、テーブルロックのみをサポートし、TEXTとBLOBデータ型はサポートしない

アプリケーションシーン:高速位置決めデータ

区別する
きのうとくせい
InnoDB
MySIAM
Memory
取引
サポート
ロック
Row
Table
Table
MVCC
サポート
BT_index
サポート
サポート
サポート
Clustered_Index
サポート
Hash_Index
サポート
サポート
Full_Index
サポート
サポート
Index_Cache
サポート
サポート
サポート
Data_Cache
サポート
サポート
F_Key
サポート
2.索引
インデックスの利点:簡単に言えば、クエリーインデックスを高速化する欠点です.
1.テーブルの更新効率を低下させる(インデックステーブルも更新する必要があるため)
2.ディスク容量の追加使用
データ量が非常に大きい場合にインデックスを作成すると、ブロックなどの問題が発生します.
2.1インデックス方法

B-Tree:ほとんどのストレージエンジンはB-Treeを使用してデータを格納し、データの速度を速める(フルテーブルスキャンを必要としないため)

.

Hash:hashテーブルに基づいてテーブルデータを記憶する、フィールドをhashして生成するハッシュコードをhashテーブルにKeyとして格納する.Value値は、そのレコードを指すポインタ

である.
2.2インデックスタイプ

クラスタリングインデックス:テーブルデータはインデックスの順序で格納、すなわちインデックス順序と記録の物理順序が一致し、1枚のテーブルには通常1つのクラスタリングインデックスしか存在しない.なぜなら、物理順序は1つ(InnoDBに対してリーフノードが実際のデータ行を格納)

しかないからである.

非クラスタリングインデックス:テーブルデータの格納順序とインデックス順序は無関係(MyISAMに対して:リーフノードはデータページを指す論理ポインタを格納)

.

プライマリ・キー・インデックス:データ列の重複は許されず、NULLは許されない.1つのテーブルに1つのプライマリ・キーしかありません

InnoDB:プライマリ・キー・インデックスは、B+Treeデータ構造に基づいてクラスタ・インデックス

に組織する.

MyISAM:プライマリ・キー・インデックスもB+Treeデータ構造に基づいて組織するが非クラスタリング・インデックス

である.

一意インデックス:データ列は重複を許さず、NULLの値を許容し、1つのテーブルは複数の列が一意インデックス

を作成することを許可する.

通常インデックス:基本的なインデックスタイプであり、一意性の制限はなく、NULL値

を許可する.

結合インデックス:複数のカラム値からなる1つのインデックスは、結合検索に特化しており、インデックス結合(複数の単一カラムインデックス)

よりも効率的です.

ハッシュインデックス:hashテーブルデータ構造を使用して組織されたストレージテーブルデータ(InnoDBにおける適応ハッシュによる辞書タイプの単一レコードクエリーの高速化)

.

全文インデックス:検索エンジン(MyISAMテーブルまたはB-Tree組織)

と同様に、テキスト内のキーワードを検索します.
非クラスタリングインデックス:補助インデックスとも呼ばれ、通常は補助インデックスによってクラスタリングインデックスを見つけて記録データを見つけるので、Bツリー構造では、リーフノードのデータドメインには会食インデックスが格納されている
魂三問
1.なぜツリーを使用しないのか:運が悪いとクエリの効率が非常に低下する
2.AVLツリーを使用しない理由:メンテナンスコストが高く、高すぎるとクエリ効率が低下する
3.なぜB-Treeツリーを使用しないのか:非リーフノードがデータを格納すると、ディスクIOのオーバーヘッドが増大し、メモリにインデックスを追加できない
2-3.インデックステクニック
1.インデックスにNULLのあるカラムは含まれません.短いインデックス3を使用する.インデックス列はクエリー時に1回のみ使用されます.like文の操作注意%の使用5.列上で演算を行うな.NOTや!=等操作7.インデックスは、重複率の低いフィールド8に作成する.注意Join操作は、プライマリ・キーと外部キーのデータ型が一致していることに注意してください.
2-4.インデックス解析
Explainコマンド:SQL文の実行効果の重点フィールド1:key:MySQLが実際に使用するキー(インデックス)を表示するのに役立ちます.インデックスが選択されていない場合、キーはNULL重点フィールド2:type:パフォーマンスが悪いから良い
all:全テーブルスキャン、すべてのデータ行のスキャン
index:すべてのインデックスノードをスキャン
range:クエリー時にインデックスに基づいて範囲のスキャンが可能
index_subquery:サブクエリでは、一意のインデックス以外のインデックスに基づいてスキャンされます.
unique_subquery:サブクエリで一意のインデックスに基づいてスキャン
index_merge:マルチレンジスキャン.2つのテーブルが接続されている各テーブルの接続フィールドには、インデックスが存在し、インデックスが整列しており、結果が結合されています.集合の並列、交差操作に適用されます.
ref_or_null:REFと似ていますが、検索条件には、接続フィールドの値がNULLの場合が含まれます.
fulltext:全文インデックス
ref:これもインデックス・アクセスで、個別の値に一致するすべてのローを返します.ただし、条件に合致する複数のローが見つかる可能性があります.したがって、彼は検索とスキャンのブレンドに属するはずです.
eq_ref:インデックス列を使用して、1行のデータ(1行のデータに正確に)を直接参照するのは、接続クエリーで一般的です.
const,system,null:mysqlがクエリーの部分を最適化し、定数に変換できると、このアクセスタイプが使用されます.
3.ロック
前の文章は関連しているので、ここではあまり紹介しません.ここでは、デッドロックの状況についてデッドロックをまとめたいと思います.複数の事務が同じ資源上の相互占有を指します.シリアル化された条件下およびテーブル・ロックでデッドロックが発生しない非トランザクションについてロックが追加されますか?
1.手動ロック:for update
2.自動ロック:create/insert/update操作
4.最適化