リレーショナルデータベーススキーマ
ホリスティックな思考アーキテクチャ
アーキテクチャ
リレーショナルデータベースを設計する方法
1、需要一个文件存储系统（RDBMS） 2、需要一个程序实例（对存储系统进行逻辑管理） 包括:存储管理、缓存机制、SQL解析、日志管理、权限划分、容灾机制、索引管理、锁管理
指数
- なぜインデックスを使用
快速查询数据- インデックス情報のどのような種類になることができます
主键、唯一键以及普通键等インデックスのデータ構造
1、生成索引，建立二叉查找树进行二分查找 2、生成索引，建立B-Tree结构进行查找 3、生成索引，建立B+-Tree结构进行查找 4、生成索引，建立Hash结构进行查找Bツリーが定義されています。
1、少なくとも2人の子供を含むルートノード
図2に示すように、ツリー内の各ノードが子を含有するM（M> = 2）
図3は、ルートノードとリーフノードを除いて、少なくとも別のはceil（M / 2）を有する各ノードは、子供（最大値をとります）
図4に示すように、すべてのリーフノードが同じレベルであります
5、
ツリーの定義 - B +
図1に示すように、リーフノードのサブツリーポインタは、キーワードの数と同じではありません
サブツリーP 2、非リーフノード[i]は、キー値ポイント[K [i]は、K [I + 1]サブツリー
図3に示すように、非リーフノードは、データが子ノードに格納されたインデックスに使用されています
図4に示すように、すべてのリーフノードは、リーフノードのチェーンへのポインタを有しています
インデックスの欠点をハッシュ：
1、あなただけは範囲クエリを使用することはできません、「=」、「中」を満たすために
2、運用データの並べ替えを避けるために使用することはできません
3、インデックスキー問い合わせの一部を使用することはできません
図4は、スキャンテーブルを避けることができません
図5は、ハッシュ値の多くに遭遇した後に同等の性能Bツリー索引より必ずしも高くはありませんです
ビットマップ・インデックス：
いくつかのインデックスデータベースのサポートBIgMap
结论: 1、B+树的磁盘读写代价更低 2、B+树的查询效率更加稳定 3、B+树更有利于对数据库的扫描密と疎のインデックスインデックスの違い
1、密集索引文件中的每个搜索码值都对应一个索引值
2、稀疏索引文件只为索引码的某些值建立索引项 InnoDBは：
図1に示すように、主キーが集中主キー索引として定義されている場合、
主キーが定義されていない場合2、唯一の非空のテーブルの最初のインデックスは、高密度インデックスであります
図3に示すように、上記の条件が満たされていない、隠された内部InnoDBは、主キー（密なインデックス）を生成します
図4に示すように、プライマリ・キー・インデックスに関連する非プライマリ・キー値は、2つのルックアップを含む、ビットとそれに対応するキーが格納されています
見つけて、スロークエリのSQLを最適化する方法
スロースロークエリログ測位SQLよります
show variable like '%quer%' #查询数据库相关变量 'slow_query_log' ——查看是否打开了慢日志查询功能； ‘slow_query_log_file’ ——慢查询日志的存放位置； ‘long_query_time’ ——多长时间的查询被定义为慢查询,单位为 秒；show status like '%slow_queries%'; #查看有多少慢sqlこのような分析のSQLなどのツールの使用を説明します
explain + sql ;キーフィールドを説明します。
1、タイプ：
システム> constの>でeq_ref> ref>を全文> ref_or_null> index_merge> unique_sunquery> index_subquery>範囲>インデックス>すべてのインデックスと最後の二つは、すべての全表スキャンで表され、SQL最適化を必要とします。
2、余分：
フィールドは、次の2つは、MySQLはインデックスを使用できないことを考えると、効率が大幅に影響を受けるだろう、これは可能な限り最適化する必要があります。
- filesortレコードを使用した：MySQLは外部インデックス順序の結果を代表する、順序インデックスは、テーブルからコンテンツを読み取るのではなく。これは、メモリやディスク上でソートすることができます。MySQLは、「ファイルのソートと呼ばれる指標の並べ替え操作を使用して行うことができません
- 一時的な使用：クエリ結果をソートする際にmysqlが一時テーブルの使用を示しています。でクエリグループをソートし、グループ化することで順番に共通します。
SQLは変更またはインデックスを行くようにしようとしたSQL
左端のマッチング原則原因の共同インデックス
1、最左匹配原则，mysql会一直向右匹配直到遇到范围查询(>、<、between、like)就停止匹配，比如a=3 and b=4 and c>5 and d=6 如果建立（a、b、c、d）顺序的索引，d是用不到索引的，如果建立（a、b、d、c）的索引则都可以用到，a、b、d的顺序可以任意调整。
2、=和in 可以乱序，比如a=1 and b=2 and c=3建立（a,b,c）索引可以任意顺序，mysql的查询优化器会自动优化。原因：
関節指数を実行するのMySQLは、COL1（最初のフィールド）、COL2（第2フィールド）によって右ために残しているので、直接使用まで2番目のフィールドは、インデックスを使用できません
インデックスは、それをよりよく確立されています
1、数据量小的表不需要建立索引，建立会增加额外的索引开销 2、数据变更需要维护索引，因此更多的索引以为着更多的维护成本 3、更多的索引意味着也需要更多的空间
ロック
データベースのロック分類
1、粒度分類ロックによれば、ロックテーブルレベル、行レベルロック、ページレベルのロック
共有ロック、排他ロック：2.ロックレベルの部門をクリックします
図3に示すように、ロック方法で割った：自動ロック、明示的なロック
図4に示すように、操作に応じてDDLをロックし、DMLロックに分けることができます
使用5は、楽観的ロックに分割することができ、悲観的ロック
点があるのMyISAMとInnoDBの違いについてどのようなロック
MyISAMテーブルは、行レベルのロックがサポートされていないが、テーブル・レベルのロッキングのデフォルトの使用です。
适合场景： 1、频繁执行全表count语句 2、对数据进行增删改的频率不高，查询非常频繁 3、没有事务InnoDBは、行レベル・ロックとデフォルトであり、また、テーブルレベルのロックをサポートします。
1、数据增删改查都相当频繁 2、可靠性要求比较高，要求支持事务
共有ロック（データベーステーブルの読み出し）
同時状況では、テーブル（レコード）に加えて、共有ロックの場合ならば、セッションは、他の共有ロックを追加し続けることができます。
同時状況では、テーブル（レコード）を加えた排他ロックならば、共有ロックと排他ロックの両方が一緒にされません。
排他ロック（データベーステーブル上の書き込み操作）
テーブル（レコード）に加えて、共有の状況をロックダウンした場合、同時の状況では、共有ロックと排他ロックの両方が一緒ではありません。
同時状況で、テーブル（レコード）を加えた排他ロック状況下、共有ロックと排他ロックの両方が一緒にされていない場合。
インデックスを取るInnoDBのクエリは、行レベルのロックおよびロックギャップであります
インデックスを取っていないのInnoDBのクエリは、テーブルレベルのロックです
閉じるMySQLのInnoDBは自動的にトランザクションのコミット機能。
自動的に提出閉じるセットの自動コミット= 0＃;
マニュアル共有ロック：共有モードでxxxxのロックを選択します。
データベーストランザクションの4つの特徴
不可分性
一貫性
隔離
持久性
トランザクション分離レベルの下で、すべてのレベルでの同時アクセスの問題
1は、失われたアップデート（私も他の人をカバーするとき、更新テーブルのデータで更新を提出する私の前に自分自身を提出し、総務などを投入） - mysqlのデータベースレベルのすべてのトランザクション分離レベルを回避することができます
2は、ダーティリード（ない他の人によって提出されたデータを読み込む） -読み取りコミットトランザクション分離レベルは、上記に回避することができます
3、非反復可能読み取り（第読み出し及び第二読取誰も矛盾したデータが得られ、トランザクションを提出することができないので、私は前後に同じ読み取り） -避けるために、トランザクション分離レベルをrepaeatabe読み
（図4に示すように、ファントム読み取り誰もが私は矛盾読み出されたデータの数で、その結果、トランザクションを提出することができないため、最初の読み取りおよび第二読取） -シリアライズトランザクション分離レベルを回避するため
Oracleのデフォルトのトランザクションレベルがある：読み取りコミット
MySQLのデフォルトのトランザクションレベルがある：反復可能読み取り
データベースの分離レベルを表示します。
select @@tx_isolation;分離レベルの評価を設定します：
set session transaction isolation level read uncommitted;
注：SQL標準と異なる場所InnoDBストレージエンジンREPEATABLE-READ（再度読み取ることができる）トランザクション分離レベル下で使用されるネクストキーロック・ロック・アルゴリズム、こうして読み出しの魔法を生成するために避け、（例えばSQLのような他のデータベースシステムとサーバ）が異なっています。だから、デフォルトのストレージエンジンInnoDBの分離レベルでサポートされている、既に完全にSQL標準SERIALIZABLE（直列化）分離レベルを達成するために、すなわち、トランザクション分離要件を保証する（再読み込みすることができます）REPEATABLE-READです。
ファントム読み取りを回避する方法で、InnoDBの反復可能読み取り分離レベル
外観：スナップショットの読み込み（非ブロッキング） - 擬似MVCC
現在の読み取り（プラスCRUDロック）：
select .... lock in share mode; select ...for update; update,delete,insert
スナップショットの読み取り（ロック解除された非ブロック読み取り）：
select ...
内部：ネクストキーロック（行ロック+ GAPロック）
- 主キー索引または一意索引がギャップでそれをロックします
- すべてのヒットは、あなたがギャップロックを使用しない条件が唯一のレコードロックを追加する場合は、
- 一部または全部ミスヒットがギャップロックを追加する条件であれば、
- ギャップロックは非一意のインデックスまたはで行かない現在のインデックスの読み取りに使用されます。
注：ファントムを防止するために、テーブル操作の数行が、読んだときのギャップは、つまり、ギャップロックである（私はトランザクションをコミットしていないときには、テーブルの上に他の人が削除してから操作を挿入）、それはのいくつかのヒットの条件となります行の行間隔ギャップリガがロック、他のものは挿入操作を削除することはできません。
RC、非ブロッキングはどのように（スナップショットが読み）RRレベルの下でのInnoDBを読み込み
1、DB_TRX_ID（トランザクション識別子）、DB_ROLL_PTR、DB_ROW_IDフィールドのデータ線と、
2、ログを元に戻します
3、ビューを読みます
文法
グループによるグループ
- グループまたは関数としてリストされている必要があり、列名のselect句を満たします
- 句によって、各グループで定義された各グループの列関数の結果を返します
ました
関連する統計：SUM、COUNT、MAX、MIN ....