数据库索引，是数据库管理系统中一个排序的数据结构，它可以对数据库表中一列或多列的值进行排序，以协助更加快速的访问数据库表中特定的数据。通俗的说，我们可以把数据库索引比做是一本书前面的目录，它能加快数据库的查询速度。【索引保存的数据结构为B+树】
索引的作用：
若对于数据查询需求量比修改和删除需求量大的时候，简单来说只查不改可以考虑建立索引。索引也会占据额外的磁盘空间。
1)查看索引：SHOW INDEX FROM table_name;
2)创建索引：CREATE INDEX 索引名 ON 表名(字段名);
3)删除索引：DROP INDEX 索引名 ON 表名;
索引的命中：index（age，sex）
SELECT * FROM table WHERE age > 10 AND sex = 0;
会优先命中age，再命中sex，从左向右命中，不可以从右向左命中。
最左匹配原则：最左优先，以最左边的为起点任何连续的索引都能匹配上。同时遇到范围查询(>、<、between、like)就会停止匹配
使用索引
主键自动建立唯一索引。
经常作为查询条件在WHERE或者ORDER BY 语句中出现的列要建立索引。
查询中与其他表关联的字段，外键关系建立索引。
经常用于聚合函数的列要建立索引，如min()，max()等的聚合函数。
不使用索引
经常增删改的列不要建立索引。
有大量重复的列不建立索引。
表记录太少不要建立索引，因为数据较少，可能查询全部数据花费的时间比遍历索引的时间还要短，索引就可能不会产生优化效果 。
数据库引擎：传统MyISAM 和 InnoDB
传统MyISAM采用线性表存储数据，B+树存储索引，不支持事务；
InnoDB采用B+树存储索引和数据以主键作为key，支持事务；
MyISAM使用B+树作为索引结构，叶节点的data域保存的是存储数据的地址，主键索引key值唯一，辅助索引key可以重复，二者在结构上相同。 因此，MyISAM中索引检索的算法为首先按照B+Tree搜索算法搜索索引，如果要找的Key存在，则取出其data域的值，然后以data域的值为地址，去读取相应数据记录 。因此，索引文件和数据文件是分开的，从索引中检索到的是数据的地址，而不是数据。
Innodb也是用B+树作为索引结构，但具体实现方式却与MyISAM截然不同，首先，数据表本身就是按照b+树组织，所以数据文件本身就是主键索引文件。叶节点key值为数据表的主键，data域为完整的数据记录，因此InnoDB表数据文件本身就是主键索引(这也就是MyISAM可以允许没有主键，但是Innodb必须有主键的原因）。第二个与MyISAM索引的不同是InnoDB的辅助索引的data域存储相应数据记录的主键值而不是地址。换句话说，InnoDB的所有辅助索引都引用主键作为data域。
B树的搜索：从根结点开始，对结点内的关键字（有序）序列进行二分查找，如果命中则结束，否则进入查询关键字所属范围的儿子结点；重复执行这个操作，直到所对应的节点指针为空，或者已经是是叶子结点。
例如下面一个B树，那么查找元素43的过程如下：
根据根节点指针找到18、37所在节点，把此节点读入内存，进行第一次磁盘IO，此时发现43>37，找到指针p3。
根据指针p3，找到42、51所在节点，把此节点读入内存，进行第二次磁盘IO，此时发现42<43<51，找到指针p2。
根据指针p2，找到43、46所在节点，把此节点读入内存，进行第三次磁盘IO，此时我们就已经查到了元素43。
在此过程总共进行了三次磁盘IO。
相对B树，B+树做索引的优势
B+树的磁盘IO代价更低： B+树非叶子节点没有指向数据行的指针，所以相同的磁盘容量存储的节点数更多，相应的IO读写次数肯定减少了。
B+树的查询效率更加稳定：由于所有数据都存于叶子节点。所有关键字查询的路径长度相同，每一个数据的查询效率相当。
所有的叶子节点形成了一个有序链表，更加便于查找。
关于MySQL的两种常用存储引擎MyISAM和InnoDB的索引均以B+树作为数据结构，二者却有不同（这里只说二者索引的区别）
B+Tree是在B-Tree基础上的一种优化，使其更适合实现外存储索引结构，InnoDB存储引擎就是用B+Tree实现其索引结构。
从上一节中的B-Tree结构图中可以看到每个节点中不仅包含数据的key值，还有data值。而每一个页的存储空间是有限的，如果data数据较大时将会导致每个节点（即一个页）能存储的key的数量很小，当存储的数据量很大时同样会导致B-Tree的深度较大，增大查询时的磁盘I/O次数，进而影响查询效率。在B+Tree中，所有数据记录节点都是按照键值大小顺序存放在同一层的叶子节点上，而非叶子节点上只存储key值信息，这样可以大大加大每个节点存储的key值数量，降低B+Tree的高度。
B+Tree相对于B-Tree有几点不同：
将上一节中的B-Tree优化，由于B+Tree的非叶子节点只存储键值信息，假设每个磁盘块能存储4个键值及指针信息，则变成B+Tree后其结构如下图所示：
通常在B+Tree上有两个头指针，一个指向根节点，另一个指向关键字最小的叶子节点，而且所有叶子节点（即数据节点）之间是一种链式环结构。因此可以对B+Tree进行两种查找运算：一种是对于主键的范围查找和分页查找，另一种是从根节点开始，进行随机查找。
可能上面例子中只有22条数据记录，看不出B+Tree的优点，下面做一个推算：
InnoDB存储引擎中页的大小为16KB，一般表的主键类型为INT（占用4个字节）或BIGINT（占用8个字节），指针类型也一般为4或8个字节，也就是说一个页（B+Tree中的一个节点）中大概存储16KB/(8B+8B)=1K个键值（因为是估值，为方便计算，这里的K取值为〖10〗^3）。也就是说一个深度为3的B+Tree索引可以维护10^3 * 10^3 * 10^3 = 10亿 条记录。
实际情况中每个节点可能不能填充满，因此在数据库中，B+Tree的高度一般都在2~4层。mysql的InnoDB存储引擎在设计时是将根节点常驻内存的，也就是说查找某一键值的行记录时最多只需要1~3次磁盘I/O操作。
数据库中的B+Tree索引可以分为聚集索引（clustered index）和辅助索引（secondary index）。上面的B+Tree示例图在数据库中的实现即为聚集索引，聚集索引的B+Tree中的叶子节点存放的是整张表的行记录数据。辅助索引与聚集索引的区别在于辅助索引的叶子节点并不包含行记录的全部数据，而是存储相应行数据的聚集索引键，即主键。当通过辅助索引来查询数据时，InnoDB存储引擎会遍历辅助索引找到主键，然后再通过主键在聚集索引中找到完整的行记录数据。
作为单个逻辑工作单元执行的一系列操作称为事务。
其四大特性ACID：
原子性（Atomicity）：执行指令时，要么全部执行成功，要么全部失败。只要其中一个指令执行失败，所有的指令都执行失败。
一致性（Consistency）：事务的执行使数据从一个状态转换为另一个状态，但是对于整个数据的完整性保持稳定。
隔离性（Isolation）：当出现并发访问时，数据库为每个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间是相互隔离的。 即要达到这么一种效果：对于任意两个并发的事务T1和T2，在事务T1看来，T2要么在T1开始之前就已经结束，要么在T1结束之后才开始，每个事务都感觉不到有其他事务在并发地执行。
持久性（Durability）：当事务正确完成后，它对于数据的改变是永久性的。
事务的使用：
开启事务： start transaction；
……执行SQL语句……
回滚或提交： rollback/commit；
说明：rollback即是全部失败，commit即是全部成功。
并发事务导致的问题：
在许多事务去处理同一个数据时，如果没有采取有效的隔离机制，就会带来一些的问题。
● 丢失更新：撤销一个事务时，把其他事务已提交的更新数据覆盖。
【例如：小明去银行柜台存钱，他的账户里原来的余额为100元，现在打算存入100元。在他存钱的过程中，银行年费扣了5元，余额只剩95元。突然他又想着这100元要用来请女朋友看电影吃饭，不打算存了。在他撤回存钱操作后，余额依然为他存钱之前的100元。所以那5块钱到底扣了谁的？】
● 脏读：有一行数据刚更新，与此同时另一个查询读到了这个刚更新的值。这样就导致了脏读，因为更新的数据还没有进行持久化，更新这行数据的业务可能还会进行回滚操作。
【例如：小明的银行卡余额里有100元。现在他打算用手机点一个奶茶，需要付款10元。但是这个时候，他的女朋友看中了一件衣服95元，她也正在使用小明的银行卡付款。于是小明在付款的时候，程序后台读取到他的余额只有5块钱了，根本不够10元，所以系统拒绝了他的交易，告诉余额不足。但是小明的女朋友最后因为密码错误，无法进行交易。小明非常郁闷，明明银行卡里还有100元，怎么会余额不足呢？】
● 幻读也叫虚读：一个事务执行多次查询，第二次结果集包含第一次中没有或已经被删除的数据，造成两次结果不一致，只是另一个事务在这两次查询中间插入或删除了数据造成的。幻读是事务非独立执行时发生的一种现象。
【例如：事务T1对一个表中所有的行的某个数据项做了从“1”修改为“2”的操作，这时事务T2又对这个表中插入了一行数据项，而这个数据项的数值还是为“1”并且提交给数据库。而操作事务T1的用户如果再查看刚刚修改的数据，会发现还有一行没有修改，其实这行是从事务T2中添加的，就好像产生幻觉一样，这就是发生了幻读。】
● 不可重复读：一个事务两次读取同一行的数据，结果得到不同状态的结果，中间正好另一个事务更新了该数据，两次结果相异，不可被信任。
【例如：事务T1在读取某一数据，而事务T2立马修改了这个数据并且提交给数据库，事务T1再次读取该数据就得到了不同的结果。】
Tips：不可重复读和脏读的区别：脏读是某一事务读取了另一个事务未提交的脏数据，而不可重复读则是读取了前一事务提交的数据。
Tips：幻读和不可重复读都是读取了另一条已经提交的事务，所不同的是不可重复读查询的都是同一个数据项，而幻读针对的是一批数据整体（比如数据的个数）。
数据库事务的隔离级别：
事务的隔离级别有4种，由低到高分别为Read uncommitted 、Read committed 、Repeatable read 、Serializable
1.Read uncommitted（最低级别，任何情况都无法保证）
顾名思义：读未提交，就是一个事务可以读取另一个未提交事务的数据。 产生脏读
2.Read committed（可避免脏读的发生）
顾名思义：读提交，就是一个事务要等另一个事务提交后才能读取数据。产生不可重复读
若有事务对数据进行修改（UPDATE）操作时，读操作事务要等待这个更新操作的事务提交后才能读取数据，可以解决脏读问题。但假如有一个事务做了两次查询却返回了不同数据，这就是不可重复读。
3.Repeatable read（可避免脏读、不可重复读的发生）
顾名思义：重复读，就是在开始读取数据（事务开启）时，不再允许修改操作。产生幻读（看到修改，但是结果没变）
不可重复读对应的是修改（UPDATE）操作。但是可能还会有幻读问题。因为幻读问题对应的是插入（INSERT）操作。
4.Serializable（可避免脏读、不可重复读、幻读的发生） 。但是效率最低
顾名思义：序列化 Serializable 是最高的事务隔离级别，在该级别下，事务串行化顺序执行，可以避免脏读、不可重复读与幻读。但是这种事务隔离级别效率低下，比较耗数据库性能，一般不使用。
Tips：大多数数据库默认的事务隔离级别是Read committed，比如SQL Server , Oracle。
MySQL的默认隔离级别是Repeatable read。
注意：隔离级别的设置只对当前链接有效，一定要是在开启事务之前就设置数据库的隔离级别。
SQL语句优化：
怎么判断sql查询慢呢？
1、使用explain进行分析sql 查询当前sql索引使用程度，是否需要建立索引。
2、检查sql是否多表联查时，是否是小表驱动大表。
3、慎用group by + order by 操作，使用FORCE INDEX(XXX) 强制索引，进行查询。
4、检查yml文件，看一下服务器环境连接地址是否是内网IP，不是公网IP。
5、检查mysql内存分配，使用show variables like 'innodb_buffer_pool%';进行查询内存。
1.如果数据量很大，并且查询多余修改的话，可以考虑建索引，但是索引也是占磁盘空间的；
2.WHERE句子中：可以过滤掉大量数据的条件写在WHERE子句末尾或HAVING末尾；
3.避免在索引列上使用IS NULL或者IS NOT NULL；
4.尽量避免在WHERE子句中对字段进行NULL判断和表达式操作，会导致引擎放弃索引而使用全表扫描。
垂直分表：将一个表按照字段分成多个表，每个表存储其中一部分字段。一般会将常用的字段放到一个表中，将不常用的字段放到另一个表中。
垂直分表的优势：
垂直分库：按照业务对表进行分类，部署到不同的数据库上面，不同的数据库可以放到不同的服务器上面。
垂直分库的优势：
垂直拆分（分库、分表）的缺点：
水平分表：在同一个数据库内，把同一个表的数据按照一定规则拆分到多个表中。
水平分表的优势：
水平分库：把同一个表的数据按照一定规则拆分到不同的数据库中，不同的数据库可以放到不同的服务器上。
水平分库的优势：
水平拆分（分表、分库）的缺点：
在系统设计时应根据业务耦合来确定垂直分库和垂直分表的方案，在数据访问压力不是特别大时应考虑缓存、读写分离等方法，若数据量很大，或持续增长可考虑水平分库分表，水平拆分所涉及的逻辑比较复杂，常见的方案有客户端架构和恶代理架构。
