mysql 事务：

MySQL 事务次要用于解决操作量大，复杂度高的数据。比如说，在人员管理系统中，你删除一个人员，你既须要删除人员的根本材料，也要删除和该人员相干的信息，如信箱，文章等等，这样，这些数据库操作语句就形成一个事务！

• 在 MySQL 中只有应用了 Innodb 数据库引擎的数据库或表才反对事务。• 事务处理能够用来保护数据库的完整性，保障成批的 SQL 语句要么全副执行，要么全副不执行。• 事务用来治理 insert,update,delete 语句一般来说，事务是必须满足 4 个条件（ACID）：：原子性（Atomicity，或称不可分割性）、一致性（Consistency）、隔离性（Isolation，又称独立性）、持久性（Durability）。• 原子性：一个事务（transaction）中的所有操作，要么全副实现，要么全副不实现，不会完结在两头某个环节。事务在执行过程中产生谬误，会被回滚（Rollback）到事务开始前的状态，就像这个事务素来没有执行过一样。• 一致性：在事务开始之前和事务完结当前，数据库的完整性没有被毁坏。这示意写入的材料必须完全符合所有的预设规定，这蕴含材料的精确度、串联性以及后续数据库能够自发性地实现预约的工作。• 隔离性：数据库容许多个并发事务同时对其数据进行读写和批改的能力，隔离性能够避免多个事务并发执行时因为穿插执行而导致数据的不统一。事务隔离分为不同级别，包含读未提交（Read uncommitted）、读提交（read committed）、可反复读（repeatable read）和串行化（Serializable）。• 持久性：事务处理完结后，对数据的批改就是永恒的，即使系统故障也不会失落

mysql 索引：

MySQL 索引的建设对于 MySQL 的高效运行是很重要的，索引能够大大提高 MySQL 的检索速度。打个比方，如果正当的设计且应用索引的 MySQL 是一辆兰博基尼的话，那么没有设计和应用索引的 MySQL 就是一个人力三轮车。拿汉语字典的目录页（索引）打比方，咱们能够按拼音、笔画、偏旁部首等排序的目录（索引）疾速查找到须要的字。索引分单列索引和组合索引。单列索引，即一个索引只蕴含单个列，一个表能够有多个单列索引，但这不是组合索引。组合索引，即一个索引蕴含多个列。创立索引时，你须要确保该索引是利用在 SQL 查问语句的条件(个别作为 WHERE 子句的条件)。实际上，索引也是一张表，该表保留了主键与索引字段，并指向实体表的记录。下面都在说应用索引的益处，但过多的应用索引将会造成滥用。因而索引也会有它的毛病：尽管索引大大提高了查问速度，同时却会升高更新表的速度，如对表进行 INSERT、UPDATE 和 DELETE。因为更新表时，MySQL 不仅要保留数据，还要保留一下索引文件。建设索引会占用磁盘空间的索引文件。

索引的数据结构

下面讲了索引的基本原理，数据库的复杂性，以及操作系统的一些内容，目标就是让大家理解到，任何一种数据结构都不是凭空产生的，肯定有它的背景和应用场景。那么，咱们须要这些数据结构可能做什么呢？其实很简略，就是：每次查找数据的时候，把磁盘 I / O 次数限度在一个很小的数量级，最好是一个常量数量级。那么咱们就想到，如果一个高度可控的多路搜寻树，是否可能满足需要呢？在这样的背景下，B+ 树应运而生。

详解 B + 树

如上图，是一棵 B + 树。B+ 树的定义，童鞋能够自行百度，咱们只说一些重点。图中浅蓝色的块，咱们称之为一个磁盘，能够看到，每个磁盘块蕴含几个数据项（深蓝色）和指针（黄色）。如：磁盘块 1 蕴含数据 17 和数据 35，蕴含指针 P1,P2,P3，P1 指向数据小于 17 的磁盘块，P2 指向数据在 17 到 35 之间的数据所在磁盘块，P3 指向数据大于 35 的数据所在的磁盘块。实在数据存在于叶子节点，即 3，5，9，10，13，15，28，29，36，60，75，79，90，99。非叶子节点不存储实在数据，只存储指引搜寻方向的数据项，如 17、35 并不实在存在于数据表中。

B+ 树的查找过程

还是应用下面的 B + 树。假如，咱们要查找数据项 29，那么咱们首先会把磁盘块 1 由磁盘加载到内存中，此时进行了一次 I /O，在内存中用二分查找确定 29 在 17 和 35 之间，锁定磁盘块 1 的 P2 指针，内存计算工夫因为十分短（比照于 I /O）能够忽略不计，通过磁盘块 1 的 P2 指针的磁盘地址指向磁盘块 3，由磁盘加载到内存，此时进行了第二次 I /O，29 在 26 和 30 之间，锁定磁盘块 3 的 P2 指针，通过指针加载磁盘块 8 到内存，此时进行了第三次 I /O，同时内存中计算二分查找找到 29，查问完结。这一过程，一共进行了 3 次 I /O。在实在应用场景中，三层的 B + 树能够示意上百万的数据，如果上百万的数据查问只须要三次 I /O，性能进步将会是微小的。B+ 树就是一种索引数据结构，如果没有这样的索引，每个数据项产生一次 I /O，那么老本将会大大晋升。

B+ 树的性质

在下面的查找例子中，咱们能够剖析出一些 B + 树的性质：

1，I/ O 的次数取决于 B + 树的高度 H，假如以后数据表的数据为 N，每个磁盘块的数据项的数量是 M，则有：H=log(M+1)N，当数据量 N 肯定的状况下，M 越大，H 越小；而 M = 磁盘块大小 / 数据项大小，磁盘块大小也就是一个数据页的大小，是固定的，如果数据项占的空间越小，数据项的数量越多，树的高度也就越低。这也就是为什么每个数据项，即索引字段要尽量的小，比方 int 占 4 个字节，要比 bigint 的 8 个字节小一半。这也是为什么 B + 树要求把实在数据放在叶子节点内而不是内层节点内，一旦放到内层节点内，磁盘块的数据项会大幅度的降落，导致树层级的增高。当数据项为 1 时，B+ 树会进化成线性表。

2，B+ 树的数据项是复合性数据结构，比方（name，age，gender）的时候，B+ 树是依照从左到右的程序来建设搜寻树的，比方当（小张，22，女）这样的数据来检索的时候，B+ 树会优先比拟 name 来确定下一步的搜寻方向，如果 name 雷同再顺次比拟 age 和 gender，最初失去检索的数据。然而，当（22，女）这样没有 name 的数据来的时候，B+ 树就不晓得下一步该查哪个节点，因为建设搜寻树的时候，name 就是第一个比拟因子，必须依据 name 来搜寻才晓得下一步去哪里查问。比方，当（小张，男）这样的数据来检索时，B+ 树就能够依据 name 来指定搜寻方向，但下一字段 age 缺失，所以只能把名字是“小张”的所有数据都找到，而后再匹配性别是“男”的数据了。这个是十分重要的一条性质，即索引的最左匹配个性。

索引的类型

在 MySQL 中，索引分为两大类：聚簇索引和非聚簇索引。聚簇索引是依照数据寄存的物理地位为程序的，而非聚簇索引则不同；聚簇索引可能进步多行检索的速度，而非聚簇索引则对单行的检索速度很快。

在这两大类的索引类型下，还能够将索引分成四个小类：

1，一般索引：最根本的索引，没有任何限度，是咱们大多数状况下应用到的索引。

2，惟一索引：与一般索引类型，不同的是惟一索引的列值必须惟一，但容许为空值。

3，全文索引：全文索引（FULLTEXT）仅能够实用于 MyISAM 引擎的数据表；作用于 CHAR、VARCHAR、TEXT 数据类型的列。

4，组合索引：将几个列作为一条索引进行检索，应用最左匹配准则。

建设索引的准则

咱们回头来看一开始提到的慢查问，当咱们理解完索引原理之后，对慢查问的优化应该有一些想法，这里咱们先总结一下建设索引的一些准则：

1，最左前缀匹配准则。这是十分重要、十分重要、十分重要（重要的事件说三遍）的准则，MySQL 会始终向右匹配直到遇到范畴查问（>,<,BETWEEN,LIKE）就进行匹配，比方：a = 1 AND b = 2 AND c > 3 AND d = 4，如果建设（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 的查问优化器会帮你优化成索引能够辨认的模式。

3，尽量抉择区分度高的列作为索引，区分度的公式是 COUNT(DISTINCT col) / COUNT(*)。示意字段不反复的比率，比率越大咱们扫描的记录数就越少，惟一键的区分度是 1，而一些状态、性别字段可能在大数据背后区分度是 0。可能有人会问，这个比率有什么教训么？应用场景不同，这个值也很难确定，个别须要 JOIN 的字段咱们要求在 0.1 以上，即均匀 1 条扫描 10 条记录。

4，索引列不能参加计算，尽量放弃列“洁净”。比方，FROM_UNIXTIME(create_time) =‘2016-06-06’就不能应用索引，起因很简略，B+ 树中存储的都是数据表中的字段值，然而进行检索时，须要把所有元素都利用函数能力比拟，显然这样的代价太大。所以语句要写成：create_time = UNIX_TIMESTAMP(‘2016-06-06’)。

5，尽可能的扩大索引，不要新建设索引。比方表中曾经有了 a 的索引，当初要加（a,b）的索引，那么只须要批改原来的索引即可。

6，单个多列组合索引和多个单列索引的检索查问成果不同，因为在执行 SQL 时，MySQL 只能应用一个索引，会从多个单列索引中抉择一个限度最为严格的索引。

依据下面这些准则，咱们来批改开篇的慢查问：

SELECTcount(*) AS countFROM trade_bASe AS aWHEREa.trade_status = 7 AND a.create_time BETWEEN ‘2015-09-01’ AND ‘2016-01-14’ AND a.booking_source = ‘2’

依据这条 SQL，应该建设的索引是：trade_status, booking_source,create_time 的联结索引；其中，trade_status、booking_source 的程序能够颠倒，而且 create_time 的区间查问放到前面。这就是利用了索引的最左匹配准则。这一点和 oracle 刚好相同，oracle 是从右到左

慢查问的优化步骤

1，查看运行成果，是否真的很慢，次要设置 SQL_NO_CACHE。

2，WHERE 条件单表查问，锁定最小返回记录表。这句话的意思是，把查问语句的 WHERE 都利用到表中返回的记录数最小的表开始查起，单表每个字段别离查问，看哪个字段的区分度最高

3，EXPLAIN 查看执行打算，是否与 1 预期统一（从锁定记录较少的表开始查问）

4，ORDER BY LIMIT 模式的 SQL 语句，让排序的表优先查

5，多去理解业务的应用场景

6，加索引时，要参照建设索引的几大准则

7，察看后果，不合乎预期，则从新从 1 开始剖析。

索引的优化办法

1，何时应用聚簇索引或非聚簇索引：

2，索引不会蕴含有 NULL 值的列：只有列中蕴含有 NULL 值，都将不会被蕴含在索引中，组合索引中只有有一列有 NULL 值，那么这一列对于此条组合索引就是有效的。所以咱们在数据库设计时，不要让索引字段的默认值为 NULL。

3，应用短索引：假如，如果有一个数据类型为 CHAR(255)的列，在前 10 个或 20 个字符内，绝大部分数据的值是惟一的，那么就不要对整个列进行索引。短索引不仅能够进步查问速度而且能够节俭 I / O 操作。

4，索引列排序：MySQL 查问只应用一个索引，因而如果 WHERE 子句中曾经应用了索引的话，那么 ORDER BY 中的列是不会应用索引的。因而数据库默认排序能够符合要求的状况下，不要应用排序操作；尽量不要蕴含多个列的排序，如果须要，最好给这些列也创立组合索引。

5，LIKE 语句操作：个别状况下，不倡议应用 LIKE 操作；如果非应用不可，如何应用也是一个钻研的课题。LIKE“%aaaaa%”不会应用索引，然而 LIKE“aaa%”却能够应用索引。

6，不要在索引列上进行运算：在建设索引的准则中，提到了索引列不能进行运算，这里就不再赘述了。

最初，总结一下，其实任何数据库层面的优化，都抵不上利用零碎的优化，同样是 MySQL，Facebook/Google 等等都能够撑持，所以且行且珍惜吧！

前段时间，有个大佬面上了某大厂，送给我一批学习材料，整理出来，就造成了以下文档（数据库方面），次要包含 MySQL 面试题、MySQL 根底到高级到调优笔记、MySQL 常识总结、MySQL 性能调优与架构设计解析文档， 已打包好

增加小助手 VX：xuanwo008 即可获取~

因为篇幅字数起因，在这只展现具体目录及内容的截图了，有须要的敌人增加小助手 VX：xuanwo008 即可获取~