1 3つのパラダイムを教えてください？
- 最初のパラダイム（1NF）：データベーステーブルのフィールドは、単一の所有物を分割することができません。このプロパティは、整数、実数、文字、ロジックタイプ、日付タイプを含む単一の基本的なタイプで構成されています。
- 第二のパラダイム（2NF）：ファンクションキーフィールドの候補のいずれかの部分に依存して、データベーステーブルがない非キーフィールド（非キーフィールドの意思決定の場でのキーワードのいくつかの組み合わせがあることが部分的な機能の依存手段）、すなわち、すべての非キー・フィールドは、候補キーの任意のセットに完全に依存しています。
- 第三のパラダイム（3NF）は：データ非依存キーフィールド伝達関数はいずれかの候補キーワードセクションに応じてテーブルに存在しない場合に、第2のパラダイムに基づいて、第三のパラダイムに沿ったものです。依存いわゆる伝達関数、「A→B→C」が存在する場合、伝達関数の関係はC A.に依存判断することを意味 →X→非キーフィールドキーフィールドYの非キー・フィールド：このように、第3の通常のデータベーステーブルが依存関係として存在してはなりません
2 Bツリーとは何ですか？
B_TREEは、バランスのとれたマルチチャンネル探索木である動的ルックアップ非常に効率的なツリー構造です。B_TREEのすべてのノードに子ノードの最大値がB_TREE順序と呼ばれる、通常B_TREE mは単にM進ツリーと呼ばれる順序を表します。一般的には、M> = 3であるべきです。次数mのB_TREEまたは空のツリーを満たす次の条件またはM進木。
- m個の子ノードにツリーまでの各ノード
- ルートがリーフノードでない場合は、ルート・ノードは、少なくとも二つの子ノードを持っています
- 子ノードのルートノードに加えて、少なくとも他のノード（境界線M上/ 2）数
- ノードの下に示される構造、前記キーワードのノードのn数の（上位のM / 2の結合）-1 <= N <= M-1;ジ（1 <= I <= N）鍵i番目のノードにおけるnの値、およびジ<D（i + 1）のために、CI（0 <= I <= N）ノード、その子ノードへのポインタ、および尖ったCIノードのキーは、ジ以上であるとより少ないD（I + 1）より
- すべてのリーフノードが同じ層上にあり、情報なしで（外部ルックアップ障害ノード又はノードとして見ることができ、これらのノードは、実際には、これらの空のノードを示すポインタを存在しません）
同様のB_TREEバイナリ・ソートツリーの外観を検索し、差異が見つかった場合B-ツリーは、各ノードは、ノードに到達するためにタイムテーブルで、マルチキー、初見の順序付きリストであるということです、ルックアップは成功し、そうでない場合、サブツリーに対応するポインタ情報に従って見つけること指さ、それが葉ノードに到達したとき、次にツリーは、対応するキーではありません。メインアプリケーションファイルシステムやデータベースでB_TREE、B-ツリーの高い検索効率化のために、大規模なデータベースファイルがハードディスクに保存されているため、あなたは大幅にデータ検索の効率を向上させる、非常にハードドライブのアクセス回数を減らすことができます。
二分探索木やAVL木かどうかは、大量のデータが、過度のIによって引き起こされる木の深さが原因になりますとき/ Oは、読み取りおよび書き込みがあまりにも頻繁に、貧弱なクエリ効率につながるので、インデックスのために、それはマルチツリー構造になっています選択。具体的には、Bツリー、Bツリーの様々な動作は、効率的な検索の効率を確保するように、低い高さを保つことができます。
3 B +ツリーは何ですか？
B +ツリーインデックスは、InnoDBストレージエンジンを実装しました。B +ツリーはB_TREEツリー生成されたファイルシステムを必要と修正の一種すべきツリーです。以下の3点次数mのそのm次差分B_TREE B +ツリー：
- サブツリーのノードN Nキーコードが含まれています。
- すべてのリーフノードは、キーのすべての情報が含まれており、キーは、レコードへのポインタを含み、リーフノード自体は、キーのサイズと順次リンクされ、大きな子供のころによります。
- 非終端ノードは、インデックスの一部として見ることができ、ノードは、最大（または最小）キーサブツリーの唯一のルートノードを含みます。
示す三次のB +ツリー以下の図。B +ツリー内の2つのヘッドポインタ、ルートノードへのポインタは、別のキーワード最小のリーフノードを指し、通常はあります。したがって、2つの検索操作は、B +ツリー上で実行することができる：一つは小さいものから順にキーワードを見つけることであり、他は、ルートノード、ランダムサーチからのものです。B +ツリーにランダムな外観は、挿入や削除のプロセスは、B-ツリーと基本的に同様です。ターミナルノード上のキーではないが、与えられた値に等しい場合にのみルックアップで、それが終了しませんが、リーフノードまで続きます。リーフノードへのルートからのパスを取ってそれぞれに対して一度このように、B +ツリーのために、成功したか否か、を見つけます。
4なぜB +ツリーは、より適切なデータベースインデックスファイルのインデックスとBツリー以外のオペレーティングシステムの実用化ですか？
- B +ツリーディスクのコスト読み出し及び書き込みを下げる：B +ツリーポインタの内部ノード特定情報に内部ノードBが比較的小さい木であるので、キーワードではありません。同じディスク・ブロックに格納された同一の内部ノードのキーのすべての場合は、キーワードのディスクブロック数が多くを収容することができます。使い捨ては、あなたが検索したいキーワードにメモリに読み込まより、比較的、それは読み取りおよび書き込みIOの数を減らすことができ、話します。
- B +ツリーのクエリ効率、より安定している。内部ノードのためには、エンドポイントノードのファイルの内容ではなく、唯一のキーワード索引リーフ・ノードでは、その任意の検索キーは、結び目に根から葉を取る必要がありますウェイポイント。キーワードクエリと同じ長さのすべてのパス、各データのかなりの効率でクエリ結果。
- 原因B +ツリーデータベースのインデックスを使用するのではなくBツリー主：B +ツリーのリーフノードトラバーサル限り、あなたは全体のツリートラバーサルをもたらすことができるよう、そしてデータベースクエリの範囲は非常に頻繁に基づいて、Bツリーのみ行きがけすべてのことができていますノードは、効率が低すぎます。
5時にインデックスを設定しますが、どのような状況を使用することはできませんか？
- では、ファジーマッチングLIKE文の先頭に「％（0個以上の任意の文字を表します）」
- 文が索引を持たない前と後、または使用されています
- 暗黙的なデータ型の変換が存在する（例えば、VARCHAR、単一引用符が自動的にintに変換することができるなし）
- マルチカラムインデックスのために、あなたは一番左の費用収益対応の原則を満たしている必要があり、例えば、インデックスケースやCOL1 COL1、COL2またはCOL1、COL2、col3という含む効果で複数列インデックスCOL1、COL2とCOL3が、あります。
6つの長所と短所インデックス？
利点：
- その理由は、大幅の作成の主要指標であるデータ検索の速度を速めます
- テーブルとテーブル加速度との接続
- パケットデータ検索を使用して句を並べ替えた場合、また、大幅にグループ化し、発注クエリ時間を短縮することができます
- 一意のインデックスを作成することで、データベーステーブル内のデータの各行の一意性を保証することができます
短所：
- 時間：インデックスインデックスの作成とメンテナンスは、テーブル内のデータは、追加、削除、および変更するための、特に、時間を要し、インデックスは、このように、データのメンテナンスの速度を落とす、ダイナミックなメンテナンスする必要があります
- スペース：物理空間インデックスを占有する必要性
あなたが頻繁にデータを変更したい場合は、データのインデックス作成に必要な頻繁なクエリは、インデックスの使用を推奨していません。
複数のインデックスを持っている7、？
- ハッシュインデックスは、クエリの同等のため、あなたが並べ替え、クエリの範囲にすることはできませんすることはできません
- 順序付けられた配列：等価クエリと範囲クエリのため。ただし、データレコードの介在によるあなたは彼らが作成されると、すなわち、データテーブルが変更されることはありません、唯一の静的なストレージエンジンのために、背中のすべて、高いコストを移動する必要があります。
- B +インデックス：データ秩序、範囲クエリに適し
8、どのようなインデックスを作成するためのフィールドの？どのような状況下でインデックス化すべきではありませんか？
インデックスを作成する場合：
- 多くの場合、クエリフィールドとして選択
- 多くの場合、接続されているようにフィールドテーブル
- 多くの場合でグループ、の順に、背後の異なるフィールド
インデックスを作成するには適していません。
- めったに列の値の以上の繰り返しに関与していないクエリ内の列の場合、インデックス付けません
- いくつかの特殊なデータ・タイプについて、このようなテキストフィールド（テキスト）、等の、索引付けません
何がインデックスを作成するために9を見て必要がありますか？
- 非空のフィールド：あなたはNULLを格納する場合を除き、それは、NOT NULLとして指定する必要があります。MySQLでは、カラムには、彼らはより複雑なインデックス、インデックス統計、および比較演算を行うため、ヌル値は、クエリの最適化することは困難であるが含まれています。あなたは、空の文字列の代わりに0、または特別な値NULL値を使用する必要があります
- コラムの共同インデックスに変数の各値）との差の大きな離散:(度の前のフィールドの値は、することができます（）関数は、よりユニークな値フィールドの戻り値は、カウントすることによって、よりをフィールドの値の差を表示するには分散フィールドの高度
- 得られたデータを一旦ユニットとしてデータベース・ページに格納されたデータを、複数のデータストア、大きなIOオペレーション、高効率：できるだけ小さいインデックスフィールド
カテゴリー10インデックス？
- 一般的なインデックスとユニークインデックス：インデックス列の値の一意性
- 単一のインデックスと複合インデックス：列のインデックスに含まれる列の数
- クラスタ化および非クラスタ化インデックスindex：でInnoDBはインデックスもリーフノードがデータの行全体を格納されているプライマリ・キー・インデックスと呼ばれているクラスタ化。主な主キー問合せは、主キーのインデックスをスキャンする必要があります。セカンダリインデックス、また、リーフ・ノードは、コンテンツの主キー値であること、非プライマリキーインデックスとして知られています。2×2のインデックスは、主キー索引をスキャンする前に、主キーを見つけるために、インデックスツリーをスキャンする必要があります。このプロセスは、テーブルに戻って呼ばれています。
11主キーの屈折率差とユニークインデックス？
主キー索引が主キーを指し、主キーインデックスは、それが一意のインデックスの特殊なタイプです。一意のインデックスがユニークである必要がありますインデックス列の値を表しますが、自由な値を許可し、主キーを作成し、デフォルトのデータベースは、ユニークなプライマリキーのインデックスを作成します。主キーはイエスと言う、一意のインデックスである。しかし、唯一のインデックスがNULL値を許可するため、他の一方で、プライマリキーエラーに一意索引で、主キーがnull値を許可していない、あなたはユニークなインデックスが主キーであると言うことはできません。
12トランザクションとは何ですか？
データベーストランザクションは、データベースの同時実行制御の基本単位であり、結果は別の一貫した状態にある一貫した状態変数からデータベースによって実行されなければならない操作の不可分の配列です。
それは13回のトランザクション（ACID）を備えてい？
- アトミック（原子性）：トランザクションが作業の原子単位でなければならず、データ変更が、すべての実行かのいずれかが完全に実行れます。
- 一貫性（整合性）：データベースの実装では、一貫性のある状態になければならない前と後のトランザクションの一貫性は、トランザクションの実行を指します。データベーストランザクションの実行の結果は、別の一貫性のある状態にある一貫した状態から変更されなければなりません。
- 絶縁（アイソレーション）：その他の事項に干渉することはできませんトランザクションの実行：データベーストランザクションの分離レベルでの分離は、さまざまなを提供しています。すなわち、トランザクション他の同時トランザクション内のデータの操作および使用は、単離されると同時に実行される各トランザクションの間に互いに干渉することができません。
- （耐久性）永続：トランザクションが完了したら、それはデータベースのデータに変更があるためには、永続的です。システム障害が残る場合でも修正。
14トランザクション分離レベル？
- READ UNCOMMITTED：トランザクションはコミットされていない、他のトランザクションは、それが行われた変更を見ることができます
- コミット読む：ほとんどのデータベースシステムのデフォルトの分離レベルを、他のトランザクションの提出後のトランザクションは、それが変更を確認し
- 反復可能読み取り：mysqlのデフォルトの分離レベル、トランザクションが開始し、提出の間の読み取りデータが一致している、それは時間内に提出されていない、他のトランザクションは、変更を行います見ることができません
- シリアル化：同じ行、書き込みと書き込みロックの記録、読み、競合がある場合に進めるために、トランザクションを実行する前に、トランザクションの訪問は待つ必要があります後、読み取りロック、書き込みロックを追加
15トランザクションの同時実行性の問題が発生しますか？
- ダーティ読み取り：トランザクションが別のコミットされていないトランザクションからデータを読み込み、
- 非反復可能読み取り：非反復リード焦点が同じ条件下で二度異なる結果を読み出し、修正される、即ち、データが読み出され、他のトランザクションによって変更されてもよいです
- 読書マジック：マジックは二度同じではありませんレコードの数を読み出す同じ条件で強調追加または削除を読み取ります
16 MySQLのトランザクションをサポートしていますか？
MySQLのトランザクションサポートは、ストレージエンジンにMySQLサーバー自体に結び付けられますが、関係ありません：InnoDBはトランザクションである一方、MyISAMテーブルには、トランザクションをサポートしていません。
17どのようにMySQLを最適化するには？
あなたは、次の4つの側面を考慮することができます。
- SQLの最適化とインデックス
- テーブルの構造の最適化
- システム構成の最適化
- ハードウェアの最適化
18最適化のMySQL - SQLの最適化とインデックス？
SQLステートメントの場合、我々は、を介してSQLクエリの実行計画を説明し、分析し、スロークエリログをSQL効率の問題を監視することができます。クエリは、注文テーブルを説明使用して読み取ることができ、データは、クエリオプティマイザおよび他の要因によってインデックスが実際に使用されるインデックスを使用することができる操作の操作タイプ、および各テーブルの行数との間の参照テーブルを読み取ることができ分析クエリのパフォーマンスのボトルネックステートメントまたはテーブルの構造それ。
だから、SQL文を最適化するために、どのように？
- 文の挿入の最適化：複数の値を挿入
- それ以外の場合はエンジンがインデックスと全表スキャンを使用して放棄する、句！=または<>オペレータでは避けるべきです
- where句内のフィールドはnull値の判断を避けるべきで、エンジンがインデックスと全表スキャンを使用してあきらめてしまいます
- ネストされたクエリの最適化：サブクエリは、より効率的に接続することができます（参加）の代替
- それは多くの場合、代わりに存在して使用する際の良い選択肢であります
私はインデックスを作成するためのフィールド前述およびどのような状況下で索引付けされていないものを指すことができる指標を最適化します。
19最適化のMySQL - データベースのテーブル構造を最適化？
- 適切なデータ型を選択します
- 最適化のパラダイムテーブル
- 表の縦割り
- スプリットレベルのテーブル
適切なデータ型を選択します
- 問題を解決するために小さなデータ型を使用します
- （MySQLのvarchar型よりも、ハンドルに簡単にint）を単純なデータ型を使用します
- ヌル可能でない限り使用のカスタムフィールド
- テキストタイプの使用を避け、非サブテーブルを使用する際に考慮すべきことはお勧めできません
最適化のパラダイムテーブル
上記の参照は、三つの主要なパラダイムを持っていました
表の縦割り
複数のテーブルに複数の列を含む分割テーブルは、テーブルの幅は、分割手段の、以下を含む、問題を解決します。
- 単一のフィールドが同じテーブルで使用されていません
- 別のテーブルへの大規模なフィールド
- フィールドには、しばしば一緒に使用されます
この利点には、非常に明白である：明確なビジネス分割後、分割されたルールは簡単に統合したり、システム、単純なデータのメンテナンスの間で拡張するために、明確です。
スプリットレベルのテーブル
データシートのデータを解決するための表レベルの分割はあまりにも大きな問題である、各テーブルの分割レベルの構造はまったく同じです。一般に、N個のデータテーブルを二分するために使用される方法は、以下の2つが挙げられます。
- あなたは5つのテーブルに分割したい場合はIDに出演ハッシュ関数は、MOD（ID、5）の値が取られ0-4
- 異なるテーブル内の異なるhashIDストアデータの場合
表レベルの分割等、クロスパーティションテーブルのデータのクエリ、統計および運用背景レポートの問題を含む、いくつかの問題や課題を、持参するだけでなく、いくつかの具体的なメリットをもたらします。
- また、クエリの速度を向上させるために、インデックスの層数を削減しながらクエリは、データとインデックスを読み取る必要があるとき、分割後のテーブル内のページの数を減らすことができ
- 他のものは、一般的に、データを使用していないいる間テーブル内のデータは既に、特に使用されるデータの一部では、すべての地域で、または別の期間に記録されたテーブル内のそのようなデータの独立性を有しています
- 複数のデータベース間でデータを格納する必要があり、システム全体の可用性を向上させる（サブライブラリーは、一つのかごに卵を入れることはできません）
20ストアドプロシージャとは何ですか？長所と短所は何ですか？
ストアドプロシージャは、SQL文を事前に作成しています。私はより簡単に理解：ストアドプロシージャは、レコードの集合であることができ、それは単一のテーブルまたは複数のテーブルにより（例えば、いくつかの機能を実現する方法として、T-SQLステートメントコードとしてT-SQL文の数によって符号ブロックであります削除の確認）、その後、この機能を使用するときに、ライン上で彼を呼んで、このブロックに名前を付けます。ストアドプロシージャは、コンパイル済みのコードブロックであり、効率が比較的高く、別のストアドプロシージャT_SQL文多数のネットワークトラフィックは、通信速度を向上させるために低減することができるされ、データのセキュリティをある程度確保することができます。
21ドロップ、削除と切り捨ての違いは？ドロップは、削除と切り捨てはどのようなシナリオの下で使用されましたか？
ドロップでSQL、すべてを削除するには、DELETE、TRUNCATE手段が、3いくつかの違いがあります。
- すべて削除コマンドを削除し、削除したり元に戻す削除する削除実行した後、ユーザーが（commmit）を提出する必要があり、データテーブルの行のすべてまたは一部を削除したり、ロールバック（ロールバック）するには、DELETEテーブルにトリガをトリガします
- 切り捨てテーブル内のすべてのデータを削除するには、この操作はロールバックすることはできない、とTRUNCATE速く、このテーブルにトリガをトリガし、削除より少ないスペースを占有されることはありません
- データベースからテーブルを削除するには、コマンドをドロップし、すべてのデータ行、インデックス、および権限が削除され、すべてのDMLトリガーがトリガーされることはありません、このコマンドは、ロールバックすることはできません
このため、不要になったテーブル、ドロップと、行のあなたには、いくつかのデータを削除したい場合は、deleteを使用し、そして切り捨てで保持時間テーブル内のすべてのデータを削除します。
22ビューとは何ですか？そして、何のシーンビューの使用？
- ビューは、仮想テーブルである物理テーブルと同じ機能を有しています。表示、変更、操作に増やすことができ、通常のテーブルまたはテーブルの行または列の複数のサブセットに存在しようとしています。ビューへの変更は、基本的なテーブルには影響を与えません。これは、マルチテーブルのクエリに比べて、私たちはより簡単にデータを取得することができます
- 訪問者へのフィールドの露出部分だけが、私たちは仮想テーブルを構築し、図であり、
- 別のテーブルからクエリデータ、均一にクエリ内のクエリと願い、ビューを作成できるように、クエリ結果一緒に複数のテーブル、クエリはデータソースに関係なく、ビューから直接データを取得する必要がありますテーブルの違いがもたらしました
23トリガとは何ですか？
トリガが定義されたステートメントのセットをトリガ条件は、トリガの定義を満たすと実行している間、テーブルに関連付けられているデータベース・オブジェクトです。この機能は、データベースの整合性を確保するために、データベース側でアプリケーションをトリガすることができます。
24データベースには、どのような楽観と悲観的ロックのですか？
同時実行制御タスクデータベース管理システムは、両方のバリア特性へのアクセスを確保するためであり、複数のトランザクションで同じデータの均一性とデータベーストランザクションデータベースの統一を破壊しません。オプティミスティック並行性制御（楽観的ロック）と悲観的並行性制御（排他的ロック）並行性制御技術が主に使用されています。
- ペシミスティック・ロック：同時実行違反が発生したと仮定し、シールドはすべての運用データの整合性の違反であってもよいです。その特徴は、最初のロック、そして事業を取得することを特徴としています。一般的に、データベースに我々は悲観的ロックを実装するためにSELECT ... FOR UPDATEを使用します。選択し実行するためのデータベースは...行を買収するときにデータ行を更新するための時間を選択しロックするので、他の同時実行が選択...更新のためにあなたが同じ行を選択しようとした場合（行ロックが解除されるのを待っている）を除外します発生し、これロックを達成効果。更新の取得のために自動的に現在のトランザクションの終了時に解放行ロックを選択し、したがって、トランザクションで使用されなければなりません。（注：MySQLは、選択で...すべてのスキャンラインの実装はそうMySQLの場合は、インデックスの悲観的ロックの使用を決定し、全体ではなく、テーブルをスキャンすることを確認すること、更新ステートメントのためにロックされます）
- オプティミスティック・ロック：コミット操作をするときにのみ、データの整合性違反をチェックする場合と仮定同時実行の競合が発生しません。オプティミスティック・ロックはデータのみが更新されたかどうかを確認するために、事業活動に備えて更新されていない場合は、更新が最後の更新、実際のデータの時点で成功した、そうでない場合、失敗し、再試行してください。楽観的、一般的な練習をロックすると、データやタイムスタンプをロックする必要性にバージョン番号を追加することです。その後、次のとおりです。
1. SELECT data AS old_data, version AS old_version FROM …;
2. 根据获取的数据进行业务操作，得到new_data和new_version
3. UPDATE SET data = new_data, version = new_version WHERE version = old_version
if (updated row > 0) {
// 乐观锁获取成功，操作完成
} else {
// 乐观锁获取失败，回滚并重试
}
一般的には、読書とあまり書くことが使用の楽観的ロックに適している、以下の書き込みを読んで、より悲観的ロックは、より適しています。楽観的ロックは、バックオーバーヘッド比較的大きく、かつシステムの同時実行を向上させることができ、シーンのロックを取る故障の比較的小さな確率で使用するのに適している生じるオーバーヘッド悲観的ロックよりも小さくなっているが、一度ロールに失敗したロックを取るために障害が発生した場合に発生しません。
25のMyISAMとInnoDBの違いは？
MySQLのMyISAMテーブルとInnoDBストレージエンジンは、次のように彼らの違いは、以下のとおりです。
- ストレージは：MyISAMテーブルは小さな収納スペースを占有するために圧縮することができ、InnoDBはより多くのメモリやストレージを必要とし、それはデータとインデックスをキャッシュするため、メインメモリ内に専用のバッファプールを作成します。
- トランザクションサポート：MyISAMが速くInnoDBのタイプよりも数倍を実行しますが、トランザクションのサポートを提供しない、各クエリのパフォーマンスがアトミックであることを強調し、InnoDBが提供する高度データベース等のトランザクション、外部キーを備えて、トランザクションにコミット、およびロールバッククラッシュ修復能力。
- 表ロック差：のMyISAMサポートのみテーブルレベルのロック、ユーザ操作MyISAMテーブル、選択、更新、削除、挿入文が自動的にテーブルにロックされ、InnoDBはトランザクションと行レベルのロックをサポートします。行ロックが大幅にマルチユーザ同時操作のパフォーマンスを向上させるが、InnoDBの行ロック、主キーは、テーブル全体をロックする場所の有効な、非プライマリ・キーである場合を除いて。
- 外部キー：MyISAMテーブルは外部キーをサポートしていない、とInnoDBの外部キーのサポート。
- 特定のテーブルの行数：MyISAMテーブルを保存するための行の合計数ではなく、行の数は、InnoDBテーブルを保存します。
