まず、なぜ自動インクリメントの主キーを使用します
1私たちは、主キー（PRIMARY KEY）を定義した場合、その後、InnoDBは、主キー、クラスタ化インデックスとして選択されます。
主キーが明示的に定義されていない場合、それは最初のInnoDBをプライマリキーインデックスがあるとしてNULL値が含まれていない一意のインデックスを選択します。
このような一意のインデックスが存在しない場合にROWIDであるとして引用されてもよいように、内蔵のInnoDB選択ROWID 6は凝集暗黙インデックス（レコードの主キーをインクリメントするように行のROWIDを書き込み、ORACLE ROWID限りバイト暗示）。
2葉ノード、主キー配列によって自体がデータの同じピース内のリーフノード（メモリページまたはページディスクの大きさ）を必要とメインインデックス（B +ツリー）に格納されるデータ格納レコードを記録します
したがってたびに新しいレコードを挿入し、適切なノードの位置とに挿入された主キーに基づいてのMySQL、負荷率がページ（InnoDBのデフォルト15/16）に達した場合、新しいページ（ノード）を開き
新しいレコードが挿入されているテーブルがインクリメント主キー、各時間を使用している場合は3、それが満たされたとき、それは自動的に新しいページを開くし、インデックス・ノードの現在の位置に加え、その後のシーケンスを記録します
図4に示すように、各挿入主キー値がランダムで近似されるため、非インクリメント主キー（ID番号または学生番号、等の場合）、新しいレコードが既存のインデックスページに挿入されるたびに、中間位置を有していなければならない場合
この時点で、MySQLのも目的のページがディスクに書き戻され、キャッシュからクリアされている可能性があり、適切な位置や動きのデータに新しいレコードを注文しなければならなかった、あなたは多くのオーバーヘッドを追加し、ディスクからリードバックする必要があります
同時に頻繁に移動では、ページング操作は、破片の多くを引き起こしたコンパクトな索引構造ではなかった、フォローアップは、OPTIMIZE TABLEのと最適化フィルページでテーブルを再構築しなければなりませんでした。
第二に、なぜ効率指標を改善するためのデータを使用
- インデックスデータストレージが発注されます
- インデックスデータによって順序付け場合にインデックスレコードを横断することなく、クエリです
- 極端な場合には、二分探索効率のデータクエリ効率指数はLOG2（N）に近づきます
三つの違い、B +ツリーインデックスとハッシュインデックス
B +ツリーは、よりバランスのとれたツリーであり、各リーフノードまでのルートからの高さの差はこれ以上1以下であり、同一階層内のノード間で互いにリンクへのポインタを有し、以下に示すように、順序付けされていません。
ハッシュインデックスはB +ツリーと同様に、特定のハッシュアルゴリズムを使用する新たなハッシュ値のキータームあるルートからリーフノードにステップごとのように見える必要がない単一のハッシュアルゴリズムを使用して取得されることが可能です以下に示すように、不規則。
第四に、ハッシュインデックスの利点：
同等のクエリは、ハッシュインデックスは、絶対的な優位性を持っている（前提がある：重複キー値のない多く、もし多数の時に重複キー値、いわゆるハッシュ衝突があるため、ハッシュインデックスは非効率的です）
第五には、ハッシュインデックスは、該当のシナリオではありません。
- これは、範囲クエリをサポートしていません。
- それは完全なシーケンシングをインデックスサポートしていません。
- これは、最も左前方一致ルールの共同インデックスをサポートしていません。
通常、このようなハッシュインデックスでは、次のシーンのようにほとんどのシーンに適しB +ツリーインデックス構造は、より多くの利点があります：
データ記憶されたリピートは、（大きなベースを言うことである）列データクエリベースに相当する非常に低い場合、ヒープテーブルでは、問い合わせの余地がない、例えばハッシュインデックスに特に適した時間のないソートは、存在しませんこのSQL：
# 仅等值查询
select id, name from table where name='李明'; B +ツリーインデックス、それはリアルタイムの監視を使用するテーブルにインデックスを使用して一般的に使用されるInnoDBのデフォルトエンジン。
あなたが確立ハッシュインデックスは、「適応ハッシュインデックスバッファ」のメモリで、クエリの効率を向上させることができると信じている場合は（InnoDBの適応ハッシュインデックスにオープンデフォルト）自動的に作成されたハッシュインデックスです。
テーブルはほぼほとんどのバッファプールの場合、同等のクエリスピードアップするためにハッシュインデックスを構築する場合は、検索モードを観察することで、MySQLは、接頭辞インデックスキーのハッシュインデックスが確立されて使用されます。
注：一部のワークロードでは、パフォーマンス改善のための外観は、追加の検索インデックス状況を監視し、ハッシュインデックスによってもたらさハッシュテーブル構造のコストを維持するよりもはるかに大きいもたらしました。
しかし、時には、高負荷条件の下で、適応ハッシュインデックスは、追加の読み取り/書き込みロックは、結合操作をこのような高い同時実行など、競争をもたらすでしょう。操作および％ワイルドカード操作は適応ハッシュインデックスには適用されないように、あなたは、適応ハッシュインデックスをオフにすることができます。
第六に、BツリーとB +ツリーの違い
1、Bツリー、NULの鍵及びデータ、ツリー内のすべてのノードこと、及びリーフノードポインタを格納する各ノード、リーフノードは、任意のキーワード情報が含まれていません。
2、B +ツリーは、リーフノードのすべては、すべてのキーワードの情報が含まれており、キーレコードを指すポインタを含み、葉ノード自体が順次連結されたサイズと大キーワード小児期に応じて
すべての非終端ノードは、インデックスの一部として見ることができ、ノードは、最大（または最小）キーサブツリーの唯一のルートノードを含みます。（Bツリーのエンドノードではなく、また、効果的な見つけるために必要な情報が含まれています）
七、为什么说B+比B树更适合实际应用中操作系统的文件索引和数据库索引？
1、B+的磁盘读写代价更低。
B+的内部结点并没有指向关键字具体信息的指针，因此其内部结点相对B树更小。
如果把所有同一内部结点的关键字存放在同一盘块中，那么盘块所能容纳的关键字数量也越多。一次性读入内存中的需要查找的关键字也就越多。相对来说IO读写次数也就降低了。
2、B+-tree的查询效率更加稳定。
由于非终结点并不是最终指向文件内容的结点，而只是叶子结点中关键字的索引。所以任何关键字的查找必须走一条从根结点到叶子结点的路。所有关键字查询的路径长度相同，导致每一个数据的查询效率相当。
八、MySQL联合索引
1、联合索引是两个或更多个列上的索引。
对于联合索引:Mysql从左到右的使用索引中的字段，一个查询可以只使用索引中的一部份，但只能是最左侧部分。
例如索引是key index (a,b,c). 可以支持a 、 a,b 、 a,b,c 3种组合进行查找，但不支持 b,c进行查找 .当最左侧字段是常量引用时，索引就十分有效。
2、利用索引中的附加列，您可以缩小搜索的范围，但使用一个具有两列的索引不同于使用两个单独的索引。
复合索引的结构与电话簿类似，人名由姓和名构成，电话簿首先按姓氏对进行排序，然后按名字对有相同姓氏的人进行排序。
如果您知道姓，电话簿将非常有用；如果您知道姓和名，电话簿则更为有用，但如果您只知道名不知道姓，电话簿将没有用处。
九、什么情况下应不建或少建索引
1、表记录太少
2、经常插入、删除、修改的表
3、数据重复且分布平均的表字段，假如一个表有10万行记录，有一个字段A只有T和F两种值，且每个值的分布概率大约为50%，那么对这种表A字段建索引一般不会提高数据库的查询速度。
4、经常和主字段一块查询但主字段索引值比较多的表字段
十、什么是表分区？
表分区，是指根据一定规则，将数据库中的一张表分解成多个更小的，容易管理的部分。从逻辑上看，只有一张表，但是底层却是由多个物理分区组成。
十一、表分区与分表的区别
分表：指的是通过一定规则，将一张表分解成多张不同的表。比如将用户订单记录根据时间成多个表。
分表与分区的区别在于：分区从逻辑上来讲只有一张表，而分表则是将一张表分解成多张表。
十二、表分区有什么好处？
1、存储更多数据。分区表的数据可以分布在不同的物理设备上，从而高效地利用多个硬件设备。和单个磁盘或者文件系统相比，可以存储更多数据
2、优化查询。在where语句中包含分区条件时，可以只扫描一个或多个分区表来提高查询效率；涉及sum和count语句时，也可以在多个分区上并行处理，最后汇总结果。
3、分区表更容易维护。例如：想批量删除大量数据可以清除整个分区。
4、避免某些特殊的瓶颈，例如InnoDB的单个索引的互斥访问，ext3问价你系统的inode锁竞争等。
十三、分区表的限制因素
1、一个表最多只能有1024个分区
2、MySQL5.1中，分区表达式必须是整数，或者返回整数的表达式。在MySQL5.5中提供了非整数表达式分区的支持。
3、如果分区字段中有主键或者唯一索引的列，那么多有主键列和唯一索引列都必须包含进来。即：分区字段要么不包含主键或者索引列，要么包含全部主键和索引列。
4、分区表中无法使用外键约束
5、MySQL的分区适用于一个表的所有数据和索引，不能只对表数据分区而不对索引分区，也不能只对索引分区而不对表分区，也不能只对表的一部分数据分区。
十四、如何判断当前MySQL是否支持分区？
命令：show variables like '%partition%' 运行结果:
mysql> show variables like '%partition%';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| have_partitioning | YES |
+-------------------+-------+
1 row in set (0.00 sec)have_partintioning 的值为YES，表示支持分区。
十五、MySQL支持的分区类型有哪些？
RANGE分区：这种模式允许将数据划分不同范围。例如可以将一个表通过年份划分成若干个分区
LIST分区：这种模式允许系统通过预定义的列表的值来对数据进行分割。按照List中的值分区，与RANGE的区别是，range分区的区间范围值是连续的。
HASH分区 ：这中模式允许通过对表的一个或多个列的Hash Key进行计算，最后通过这个Hash码不同数值对应的数据区域进行分区。例如可以建立一个对表主键进行分区的表。
KEY分区 ：上面Hash模式的一种延伸，这里的Hash Key是MySQL系统产生的。
十六、四种隔离级别
- Serializable (串行化)：可避免脏读、不可重复读、幻读的发生。
- Repeatable read (可重复读)：可避免脏读、不可重复读的发生。
- Read committed (读已提交)：可避免脏读的发生。
- Read uncommitted (读未提交)：最低级别，任何情况都无法保证。
十七、关于MVVC
MySQL InnoDB存储引擎，实现的是基于多版本的并发控制协议——MVCC (Multi-Version Concurrency Control)
注：与MVCC相对的，是基于锁的并发控制，Lock-Based Concurrency Control
MVCC最大的好处：读不加锁，读写不冲突。在读多写少的OLTP应用中，读写不冲突是非常重要的，极大的增加了系统的并发性能，现阶段几乎所有的RDBMS，都支持了MVCC。
- LBCC：Lock-Based Concurrency Control，基于锁的并发控制
- MVCC：Multi-Version Concurrency Control
基于多版本的并发控制协议。纯粹基于锁的并发机制并发量低，MVCC是在基于锁的并发控制上的改进，主要是在读操作上提高了并发量。
十八、在MVCC并发控制中，读操作可以分成两类：
快照读 (snapshot read)：读取的是记录的可见版本 (有可能是历史版本)，不用加锁（共享读锁s锁也不加，所以不会阻塞其他事务的写）
当前读 (current read)：读取的是记录的最新版本，并且，当前读返回的记录，都会加上锁，保证其他事务不会再并发修改这条记录
十九、行级锁定的优点：
1、当在许多线程中访问不同的行时只存在少量锁定冲突。
2、回滚时只有少量的更改
3、可以长时间锁定单一的行。
二十、行级锁定的缺点：
比页级或表级锁定占用更多的内存。
当在表的大部分中使用时，比页级或表级锁定速度慢，因为你必须获取更多的锁。
如果你在大部分数据上经常进行GROUP BY操作或者必须经常扫描整个表，比其它锁定明显慢很多。
用高级别锁定，通过支持不同的类型锁定，你也可以很容易地调节应用程序，因为其锁成本小于行级锁定。
二十一、MySQL优化
- 开启查询缓存，优化查询
- explain你的select查询，这可以帮你分析你的查询语句或是表结构的性能瓶颈。EXPLAIN 的查询结果还会告诉你你的索引主键被如何利用的，你的数据表是如何被搜索和排序的
- 当只要一行数据时使用limit 1，MySQL数据库引擎会在找到一条数据后停止搜索，而不是继续往后查少下一条符合记录的数据
- 为搜索字段建索引
- 使用 ENUM 而不是 VARCHAR。如果你有一个字段，比如“性别”，“国家”，“民族”，“状态”或“部门”，你知道这些字段的取值是有限而且固定的，那么，你应该使用 ENUM 而不是VARCHAR
- Prepared StatementsPrepared Statements很像存储过程，是一种运行在后台的SQL语句集合，我们可以从使用 prepared statements 获得很多好处，无论是性能问题还是安全问题。
Prepared Statements 可以检查一些你绑定好的变量，这样可以保护你的程序不会受到“SQL注入式”攻击 - 垂直分表
- 选择正确的存储引擎
二十二、key和index的区别
key 是数据库的物理结构，它包含两层意义和作用，一是约束（偏重于约束和规范数据库的结构完整性），二是索引（辅助查询用的）。包括primary key, unique key, foreign key 等
index是数据库的物理结构，它只是辅助查询的，它创建时会在另外的表空间（mysql中的innodb表空间）以一个类似目录的结构存储。索引要分类的话，分为前缀索引、全文本索引等；
二十三、Mysql 中 MyISAM 和 InnoDB 的区别有哪些？
区别：
1、InnoDB支持事务，MyISAM不支持
对于InnoDB每一条SQL语言都默认封装成事务，自动提交，这样会影响速度，所以最好把多条SQL语言放在begin和commit之间，组成一个事务；
2、InnoDB支持外键，而MyISAM不支持。
对一个包含外键的InnoDB表转为MYISAM会失败；
3、InnoDB是聚集索引，数据文件是和索引绑在一起的，必须要有主键，通过主键索引效率很高。
但是辅助索引需要两次查询，先查询到主键，然后再通过主键查询到数据。因此主键不应该过大，因为主键太大，其他索引也都会很大。
而MyISAM是非聚集索引，数据文件是分离的，索引保存的是数据文件的指针。主键索引和辅助索引是独立的。
4、InnoDB不保存表的具体行数，执行select count(*) from table时需要全表扫描。而MyISAM用一个变量保存了整个表的行数，执行上述语句时只需要读出该变量即可，速度很快；
5、Innodb不支持全文索引，而MyISAM支持全文索引，查询效率上MyISAM要高；
如何选择：
- 是否要支持事务，如果要请选择innodb，如果不需要可以考虑MyISAM；
- 如果表中绝大多数都只是读查询，可以考虑MyISAM，如果既有读写也挺频繁，请使用InnoDB
- 系统奔溃后，MyISAM恢复起来更困难，能否接受；
- MySQL5.5版本开始Innodb已经成为Mysql的默认引擎(之前是MyISAM)，说明其优势是有目共睹的，如果你不知道用什么，那就用InnoDB，至少不会差。
二十四、数据库表创建注意事项
1、字段名及字段配制合理性
- 剔除关系不密切的字段；
- 字段命名要有规则及相对应的含义（不要一部分英文，一部分拼音，还有类似a.b.c这样不明含义的字段）；
- 字段命名尽量不要使用缩写（大多数缩写都不能明确字段含义）；
- 字段不要大小写混用（想要具有可读性，多个英文单词可使用下划线形式连接）；
- 字段名不要使用保留字或者关键字；
- 保持字段名和类型的一致性；
- 慎重选择数字类型；
-给文本字段留足余量；
2、系统特殊字段处理及建成后建议
- 添加删除标记（例如操作人、删除时间）；
- 建立版本机制；
3、表结构合理性配置
- 多型字段的处理，就是表中是否存在字段能够分解成更小独立的几部分（例如：人可以分为男人和女人）；
- 多值字段的处理，可以将表分为三张表，这样使得检索和排序更加有调理，且保证数据的完整性！
4、其它建议
- 对于大数据字段，独立表进行存储，以便影响性能（例如：简介字段）；
- 使用varchar类型代替char，因为varchar会动态分配长度，char指定长度是固定的；
- 给表创建主键，对于没有主键的表，在查询和索引定义上有一定的影响；
- 避免表字段运行为null，建议设置默认值（例如：int类型设置默认值为0）在索引查询上，效率立显；
- 建立索引，最好建立在唯一和非空的字段上，建立太多的索引对后期插入、更新都存在一定的影响（考虑实际情况来创建）；