mysql-になります知っている必要があります

1.インデックス

1.1 B + Treeインデックス

A：InnoDBのデフォルトのインデックス。インデックスを命じ、隣接するデータが存在一緒になって、順序はランダムIO IOなります。

1.1.1基礎となるデータベースのB +ツリーはなぜ

A：要約：

• リーフノードでは、Bツリーの非リーフノードは、B +ツリーの全てに格納されたデータを格納します。その結果、B +ツリーのリーフノードへのルートからのクエリ。
• B +ツリーの内部ノードよりBツリーよりも小さい、小さな読み取りおよび書き込みのコスト。

1.1.2クラスタ化インデックス（主インデックス）および非クラスタ化インデックス（セカンダリインデックス）

回答：B +ツリーインデックスは、メインインデックスと二次インデックスに分けます。

• クラスタ化インデックス（メインインデックス）：リーフノードは行全体を格納します。あなたは、キーデータを直接取得することができます。テーブルには、1つのプライマリインデックスを含めることができます。
• 非クラスタ化インデックス（二次指数）：リーフノード主キー格納値。あなたは、主キー、主キーと、メインインデックスに沿って歩く必要があります。

テーブルに1.1.3バック

A：一般的なインデックスバックテーブルには主キーインデックスツリーが再度検索、主キーの値を取得するために、一般的なインデックスツリーを検索するためのクエリを指します。

1.2ハッシュインデックス

A：O（1）時間の検索では、しかし、あなたはソートのパケットは、することができないだけで精度を見つけること。
その後、インデックスが頻繁に引用されており、高速な検索を提供し、B +ツリーインデックスのハッシュインデックスを作成します。適応ハッシュインデックス。

1.3フルテキストインデックス

：MyISAMテーブルは、テキスト、キーワード、検索戦を見つけるために使用されるフルテキストインデックスをサポートしています。InnoDBはまた、5.6.4バージョンをサポートしています。

1.4索引チューニング

1.4.1インデックス列の順序

A：フロントで最も選択インデックス。ユニークな選択指数=指標値/レコードの合計数。

1.4.2カバーインデックス

A：インデックスのみのデータ列を選択する被覆されたクエリ列が内蔵インデックスによってカバーされることを、データラインを読み出すことなく、インデックスから取得することができます。

1.4.3プレフィックスインデックス

A：選択、唯一よると、インデックスの文字列のM文字左端を。

1.4.4インデックス・プッシュダウン

A：共同インデックス、インデックスが横断され、他のフィールドの裁判官の残りの部分の前に、フィルタレコードが条件を満たしていないテーブルにデータバックの頻度や量を低減することができます。

1.5インデックスの使用シナリオ

回答：

• 多くの場合、クエリの条件に必要性が記載されていると差別があるが、それがインデックス化することができます。
• 小さなテーブル、インデックスなし、全表スキャンをすることができます。大きなテーブルにミディアム、インデックスがお勧め。
• 大きなテーブル、ビルドおよび価格指数が大きすぎる維持は、それが区分技術とのより良いです。

2.ストレージエンジン

A：MySQLはリレーショナルデータベースであり、デフォルトのポート番号は、InnoDBのと5.5の後、使用のMyISAM前3306.5.5あります。

2.1 InnoDBの

A：デフォルトのエンジンの5.5バージョンの後。デフォルトのトランザクション分離レベルは、メインインデックス反復可能読み取りは、クラスタ化インデックスで、内部の最適化の多くは（バッファ、ハッシュインデックスなどINSERT）、ホットバックアップをサポートしています。

2.2 MyISAMテーブル

A：デフォルトのエンジンの前の5.5バージョン。

2.3のMyISAMとInnoDBの差

A：次のような違いは次のとおりです。

• 行レベルのロック。MyISAM支持体は、テーブルレベルのロック、InnoDBの支持テーブル・レベルのロックと行レベルのロック。
• トランザクションサポート。MyISAMテーブルがトランザクションをサポートしていない、InnoDBはトランザクションのサポートとクラッシュリカバリを提供します。
• 外部キー。MyISAMテーブルは、外部キーをサポートしていない、InnoDBの外部キーがサポートされています。
• InnoDBは、大量のデータを扱うことができ、マルチバージョン同時実行制御をサポートしています。
• MyISAMテーブルは、フルテキストインデックスをサポートしています。

要約する：InnoDBは、行レベルのロックをサポートするトランザクション、外部キー。

3.トランザクション

A：トランザクションは、オペレーションの論理的集合であり、または実行または実行されません。

3.1の4つのプロパティACID

A：ACID。

• アトミック（原子性）：トランザクションが実行の最小単位であり、いずれかの全てが実行またはすべての実行されません。
• 一貫性（整合性）：データベースの状態が一貫していることを保証するために、同じデータを複数のトランザクションは、結果は同じで読み取ります。
• 分離（隔離）：同時複数のトランザクションは、各トランザクションが他のトランザクションによる干渉を受けません。
• 永続性（耐久性）：トランザクションがコミットされると、この変更はデータベースに保存されます。

同時トランザクション3.2の問題

• ダーティリードは（ダーティリード）：トランザクションAはトランザクションがコミットされていないデータ変更B、Bのロールバック、一貫性のないデータを読み込み、A.
• ロスト変更（ロストを変更する）：トランザクションAとBが同時に変更Aを提出すること、データを読み、修正Bのカバレッジは、その後の修正Aさんを提出します。
• 非反復可能読み取り（リピート不可能リード）2つのリードデータトランザクションの間、トランザクションが一貫性のないデータが得られ、変形Bを更新したAが二回読み取られます。
• マジックリーディング（ファントムリード）2つのリードデータとの間のAトランザクションが、データの矛盾を読み取るレコードの数倍になり、トランザクションB増加が記録されています。
  注：マジックリーディング指を上に変更します。繰り返し不可能読みインデックスの変更が発生します。

3.3分離レベル

A：MySQLのは、4つの分離レベルを定義します。

• 非コミット読み取り（読み取りコミット）：データを読み取ることができる最低レベルが提出されていません。ダーティリード起こり、ファントムは、非反復可能読み取りを読み込みます。
• 読み取りコミット（コミット読取り）：すでに提出されたデータを読み取ることができます。防ぎダーティ・リード。
• 反復可能読み取り（反復-読む）：読み取り書き込みトランザクションは、すべてのライト・トランザクションをブロックし、取引を禁止しました。防ぎダーティ・リードと非反復可能読み取り。InnoDBのデフォルトの分離レベル。
• シリアライズ（直列化）：最高レベル。順番に実行されるすべてのトランザクションは、互いに干渉しないであろう。3つの業務の問題を停止します。

4.ロック機構

4.1ポイントの大きさに応じて

A：表レベルのロックと行レベルのロックに分割されます。

• テーブル・レベルのロック：ロックの最大サイズ。テーブル全体のロック、リソース消費、速いロック、デッドロックフリーが、ロック競合の可能性が高いです。
• 行レベルロック：ロック最小の細かさ。現在のオペレーティング・ラインロック、遅い、大きな支出をロックし、デッドロックが、大幅に紛争を減らします。

4.1.1共通の行レベルロック

A：3があります。

• レコードのロック：片道ロック、ロック予選ライン。
• ギャップロック：録画自体を除くギャップロック、ロック範囲、。
• ネクストキーロック：レコード+ギャップ 、 ロックレンジ、含むレコードそのもの。

4.1.2テーブルロックの使用シナリオ

A：トランザクションが行レベルロック、デッドロックのロールバックを使いやすく、より複雑です。より良いデータ更新大テーブル、テーブル・レベルのロッキング効率の最も。

行レベルロックは、テーブル全体をロックします4.1.3

A：更新されたカラムがインデックス化されていない、それが直接、テーブル全体をロックします。

4.2ポイントから書き込み可能です

A：あなたは、さらに共有ロックと排他ロックに分けることができます。

• 共有ロック（共有ロック）：読み込みロック。他のユーザーによってロックされたリソースを読み取るために、しかし、すべてのリソースにSロックが解放されるまで変更することはできません。
• 排他ロック（排他ロック）：書き込みロック。データのトランザクションTプラスXロック、唯一のロックが解除されるまで、T、Xを変更することが許さお読みください。アップデートでは、挿入、更新、削除などの操作は、常に排他ロックを適用します。

4.3デッドロック

A：MySQLは、デッドロックにあるデータの行によって引き起こされるロック用のロー・レベル・ロックを使用して複数のトランザクション。

4.3.1ソリューション

A：2つの領域に分割。
運用レベル：

• 順序指定されたリソースへのアクセスのロック。（食事は、オペレーティングシステムに問題を哲学者）
• 多くのリソースとしてロック一度同じトランザクション。
• 小さなトランザクションにトランザクション分割。

データベース設定：

• 設定されたタイムアウト。InnoDBのデフォルトは50代です。
• オープンデッドロック検出。デッドロックが発生した場合、トランザクションのデッドロックチェーンの収益は、その他の事項は、引き続きそうあること。

4.4悲観的ロックと楽観的ロック

A：に分かれて：

• 悲観的ロック：実現のデータベースのロック機構を使用し、全体のデータ処理がロックされ、保証独占。
• オプティミスティック・ロック：CASを達成。満場一致現在のトランザクションによるデータテーブルとデータのデータは、操作を実行するかどうかを決定するかどうか。

ABAの問題4.4.1楽観的ロック

A：追加のメカニズムを記録するデータのバージョンやタイムスタンプを使用して。
ABAの問題：トランザクションがデータX A、Y情勢はB、バックに変更し、Aを変更読み取ると、データが実際には変更さ並行性の問題が起こったが、トランザクションは、Xのデータが利用可能で変更はありませんが発生しました。

大きなテーブルの最適化

：単一のテーブルには、データベースのパフォーマンスが大幅に低下し、数が多すぎる最適化の一連の必要性を記録します。

5.1定義されたデータの範囲は

データを照会するための条件データの範囲を限定する最も簡単な手段。

5.2個別の読み取りと書き込み

マスタープロセスは、書き込みや、高いリアルタイムの読み出し動作を読み出し動作を処理するために、サーバから。

• 実装：追加のプロキシサーバーは、要求がサーバから来たにアプリケーションを転送することを決定しました。
• 理由：大幅に低減ロック競合、冗長交換可用性、サーバのMyISAMから利用可能なリソースの保全。
  

5.3スプリット水平

同じ構造、A2、A3ストレージ、各サブテーブルのデータの一部のみを複数に水平分割表A表A1を分割。
サブテーブルのライブラリとサブライブラリーのサブテーブルに細分化。

• ライブラリサブテーブル：子供はまだ同じ物理マシンのリソースの競合が、まだデータベーステーブルのインスタンスです。
• サブライブラリーのサブテーブル：異なるデータベースに散在子テーブル。

長所：ビジネス変換は簡単です。単一のテーブルには、データの過負荷の問題を解決します。
短所：ライブラリ全体の一貫性を確保することは困難で、貧しい人々は、関連するパフォーマンスに参加し、拡張やメンテナンスがあまりにも難しいです。

5.4垂直分割

垂直ベースと垂直サブテーブルに細分化。

• 垂直ライブラリ：事業セグメントに基づいて、データベース、各事業は独自のデータベースを持っているので、ということ。
• 垂直表：列ベースのセグメンテーションデータテーブル、表1-7、表1-4の列は、行及び15-7の列に分割されます。

長所：ビジネスデカップリング、高い同時実行の下でパフォーマンスを向上させます。
欠点：サービスの複雑化; 主キーの冗長性、大量のデータを解像度の必要なレベルで、解決されません。

分割後5.5問題

1. トランザクションの一貫性
   二相は、パフォーマンスの低下をコミットします。通常、最終的な一貫性を追求、問題のトランザクション補償を。
2. ページングやソート
   のソートフィールドの非断片化フィールドを、テーブル内のサブソートする必要が、その後、要約はソートされ、最終的にはユーザーに返さ。
3. グローバルに一意の主キー
   の自動インクリメントの主キーサブライブラリーは、需要を満たすことができないの使用ので、主キーなどの分散グローバルに一意なID。
   注：それは、このようなシャーディング-JDBC、アトラスとして、成熟したミドルウェアのために推奨され、コバー

6. MySQLのアーキテクチャと実装プロセス

6.1インフラストラクチャ

A：MySQLサーバでは層とストレージエンジン層に分かれています。

• サーバー層：この実装では、クロスストレージエンジンの機能、などのビュー、トリガ、関数、などは、バイナリログログがあります。
• ストレージエンジン：データ保存と検索を担当します。一般InnoDBは、モジュールを担持するredoログを使用しました。

6.2基本的なコンポーネント

A：サーバー層は5つの主要コンポーネントがあります。

• コネクタ：認証と権限の設定。
• クエリキャッシュ：クエリを実行する前に、最初の結果セットがキャッシュされません確認してください。（8.0の後に放棄されました）
• アナライザ：なしキャッシュヒットは、その後、アナライザの字句や文法解析を入力してください。
• Optimizerは：MySQLのによると、最適なプログラムの実施を検討しました。
• アクチュエータ：ユーザーは、ステートメントが実行され、許可、コールのストレージエンジンを持っています。

6.3実行プロセス

6.3.1クエリ

権限チェック---->クエリキャッシュ---->アナライザ---->オプティマイザ---->権限チェック---->アクチュエータ---->エンジン

6.3.2更新ステートメント

アナライザ----> ----チェック権限>エフェクター---->エンジン----> REDOログの準備----> binlogの ---->のREDOコミットログ
ボブを変更します年齢、例えば：

• 最初のクエリにジョー・スミス、このデータを、キャッシュとキャッシュがある場合。
• クエリステートメントを取得し、年齢は19に変更されました。
• エンジンAPIインターフェースコールは、このラインデータ、状態に入るための準備この時点でメモリに記憶されたInnoDBエンジンデータも記録REDOログ、REDOログを書き込みます。
• 通知アクチュエータ、完全な実行、あなたが提出することができます。
• アクチュエータ通知レコードのbinlog、エンジンインターフェース呼び出しを受けた後、状態の提出のためにREDOログを提出します。
• アップデートは完了です。

7.ロギングモジュールおよびキーワードの区別

7.1ログモジュール

A：MySQLの主なredoログおよびバイナリログ。

• redoログ（REDOログ）：InnoDBの固有の、物理ログ。どのデータ・ページが変更された記録。
• ビンログ（アーカイブログ）：サーバー層が来る、論理ログ、SQL文のこの変更の記録。一般データ記録の精度を確保するために使用されるバイナリフォーマットを行。

7.1.1 redoログとbinlogの2フェーズ・コミット

A：データの一貫性を確保するために、2つの段階に分けて提出しました。エンジンデータ保持を調製redoログ- >バイナリログアクチュエータ信号が受信される- > redoログコミットアクチュエータが呼び出す
ような異常なダウンタイムの提出のために、完全かどうかを決定する最初のredoログ直接提出を完了MYSQL。戻ったばかりのトランザクションを完了redoログ、またはロールを提出し続ける、ビューのbinlogが完了すると、ステータスを準備redoログ。

7.1.2 MySQLのなぜ彼が突然遅く見えませんでした

A：データベースを更新すると、ログを書き込むための、およびディスクを更新するための他の適切な時間。フルredoログは、必要なときにフラッシュ汚れたページをディスクに、書き込みデータを、これは遅く、それが実行されますです。

7.2ここで、GROUP BYおよびキーワードを有します

A：次のように3つのキーが要約されています。

• ここで生成された画面に使用されるラインから句。
• where句へのパケット出力によって基;
• スクリーニングラインからの結果によりパケット基を有するため。

7.2.1となる違い

A：ラインの使用前のパケット。パケットを使用した後、グループのために、缶最大、平均他の集計関数。

7.2.2実行順序

削除を備えた修飾されたデータを見つける---->グループグループ化----> ----集合関数が各グループについて計算される>基の望ましくありません

8.最適化

参考https://www.cnblogs.com/huchong/p/10219318.html著者：風を聞きます。