作者：Snailclimb
连结：https://segmentfault.com/a/1190000019619667?utm_source=tuicool&utm_medium=referral
前言：
这篇花文章是我花了几天时间对之前总结的MySQL知识点做了完善后的产物，这篇文章可以用来回顾MySQL基础知识以及备战MySQL常见面试问题。
什么是MySQL?
MySQL 是一种关系型数据库，在Java企业级开发中非常常用，因为 MySQL 是开源免费的，并且方便扩充套件。阿里巴巴数据库系统也大量用到了 MySQL，因此它的稳定性是有保障的。MySQL是开放源代码的，因此任何人都可以在 GPL(General Public License) 的许可下下载并根据个性化的需要对其进行修改。MySQL的预设埠号是3306。
事务相关
什么是事务?
事务是逻辑上的一组操作，要么都执行，要么都不执行。
事务最经典也经常被拿出来说例子就是转账了。假如小明要给小红转账1000元，这个转账会涉及到两个关键操作就是：将小明的余额减少1000元，将小红的余额增加1000元。万一在这两个操作之间突然出现错误比如银行系统崩溃，导致小明余额减少而小红的余额没有增加，这样就不对了。事务就是保证这两个关键操作要么都成功，要么都要失败。
事物的四大特性(ACID)介绍一下?
原子性： 事务是最小的执行单位，不允许分割。事务的原子性确保动作要么全部完成，要么完全不起作用；一致性： 执行事务前后，资料保持一致，多个事务对同一个资料读取的结果是相同的；隔离性： 并发访问数据库时，一个使用者的事务不被其他事务所干扰，各并发事务之间数据库是独立的；永续性： 一个事务被提交之后。它对数据库中资料的改变是持久的，即使数据库发生故障也不应该对其有任何影响。并发事务带来哪些问题?
在典型的应用程序中，多个事务并发执行，经常会操作相同的资料来完成各自的任务（多个使用者对统一资料进行操作）。并发虽然是必须的，但可能会导致以下的问题。
脏读（Dirty read）: 当一个事务正在访问资料并且对资料进行了修改，而这种修改还没有提交到数据库中，这时另外一个事务也访问了这个资料，然后使用了这个资料。因为这个资料是还没有提交的资料，那么另外一个事务读到的这个资料是“脏资料”，依据“脏资料”所做的操作可能是不正确的。丢失修改（Lost to modify）: 指在一个事务读取一个数据时，另外一个事务也访问了该资料，那么在第一个事务中修改了这个资料后，第二个事务也修改了这个资料。这样第一个事务内的修改结果就被丢失，因此称为丢失修改。例如：事务1读取某表中的资料A=20，事务2也读取A=20，事务1修改A=A-1，事务2也修改A=A-1，最终结果A=19，事务1的修改被丢失。不可重复读（Unrepeatableread）: 指在一个事务内多次读同一资料。在这个事务还没有结束时，另一个事务也访问该资料。那么，在第一个事务中的两次读资料之间，由于第二个事务的修改导致第一个事务两次读取的资料可能不太一样。这就发生了在一个事务内两次读到的资料是不一样的情况，因此称为不可重复读。幻读（Phantom read）: 幻读与不可重复读类似。它发生在一个事务（T1）读取了几行资料，接着另一个并发事务（T2）插入了一些资料时。在随后的查询中，第一个事务（T1）就会发现多了一些原本不存在的记录，就好像发生了幻觉一样，所以称为幻读。不可重复度和幻读区别：
不可重复读的重点是修改，幻读的重点在于新增或者删除。
例1（同样的条件, 你读取过的资料, 再次读取出来发现值不一样了 ）：事务1中的A先生读取自己的工资为 1000的操作还没完成，事务2中的B先生就修改了A的工资为2000，导 致A再读自己的工资时工资变为 2000；这就是不可重复读。
例2（同样的条件, 第1次和第2次读出来的记录数不一样 ）：假某工资单表中工资大于3000的有4人，事务1读取了所有工资大于3000的人，共查到4条记录，这时事务2 又插入了一条工资大于3000的记录，事务1再次读取时查到的记录就变为了5条，这样就导致了幻读。
事务隔离级别有哪些?MySQL的预设隔离级别是?
SQL 标准定义了四个隔离级别：
READ-UNCOMMITTED(读取未提交)： 最低的隔离级别，允许读取尚未提交的资料变更，可能会导致脏读、幻读或不可重复读。READ-COMMITTED(读取已提交)： 允许读取并发事务已经提交的资料，可以阻止脏读，但是幻读或不可重复读仍有可能发生。REPEATABLE-READ(可重复读)： 对同一字段的多次读取结果都是一致的，除非资料是被本身事务自己所修改，可以阻止脏读和不可重复读，但幻读仍有可能发生。SERIALIZABLE(可序列化)： 最高的隔离级别，完全服从ACID的隔离级别。所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。 隔离级别 脏读 不可重复读 幻影读 READ-UNCOMMITTED √ √ √ READ-COMMITTED × √ √ REPEATABLE-READ × × √ SERIALIZABLE × × × MySQL InnoDB 储存引擎的预设支援的隔离级别是 REPEATABLE-READ（可重读）。我们可以通过SELECT @@tx_isolation;命令来检视
mysql> SELECT @@tx_isolation;
+-----------------+
| @@tx_isolation |
+-----------------+
| REPEATABLE-READ |
+-----------------+
复制程式码
这里需要注意的是：与 SQL 标准不同的地方在于InnoDB 储存引擎在 **REPEATABLE-READ（可重读）事务隔离级别下使用的是Next-Key Lock 锁算法，因此可以避免幻读的产生，这与其他数据库系统(如 SQL Server)是不同的。所以说InnoDB 储存引擎的预设支援的隔离级别是 REPEATABLE-READ（可重读） 已经可以完全保证事务的隔离性要求，即达到了 SQL标准的SERIALIZABLE(可序列化)**隔离级别。
因为隔离级别越低，事务请求的锁越少，所以大部分数据库系统的隔离级别都是READ-COMMITTED(读取提交内容):，但是你要知道的是InnoDB 储存引擎预设使用 **REPEATABLE-READ（可重读）**并不会有任何效能损失。
InnoDB 储存引擎在 分散式事务 的情况下一般会用到**SERIALIZABLE(可序列化)**隔离级别。
索引相关
为什么索引能提高查询速度
以下内容整理自： 地址： juejin.im/post/5b55b8… 作者 ：Java3y
先从 MySQL 的基本储存结构说起
MySQL的基本储存结构是页(记录都存在页里边)：
各个资料页可以组成一个双向连结串列每个资料页中的记录又可以组成一个单向连结串列每个资料页都会为储存在它里边儿的记录生成一个页目录，在通过主键查询某条记录的时候可以在页目录中使用二分法快速定位到对应的槽，然后再遍历该槽对应分组中的记录即可快速找到指定的记录以其他列(非主键)作为搜寻条件：只能从最小记录开始依次遍历单链表中的每条记录。所以说，如果我们写select * from user where indexname = 'xxx'这样没有进行任何优化的sql语句，预设会这样做：
定位到记录所在的页：需要遍历双向连结串列，找到所在的页从所在的页内中查询相应的记录：由于不是根据主键查询，只能遍历所在页的单链表了很明显，在资料量很大的情况下这样查询会很慢！这样的时间复杂度为O（n）。
索引做了些什么可以让我们查询加快速度呢？其实就是将无序的资料变成有序(相对)：
要找到id为8的记录简要步骤：
很明显的是：没有用索引我们是需要遍历双向连结串列来定位对应的页，现在通过 “目录” 就可以很快地定位到对应的页上了！（二分查询，时间复杂度近似为O(logn)）
其实底层结构就是B+树，B+树作为树的一种实现，能够让我们很快地查找出对应的记录。
以下内容整理自：《Java工程师修炼之道》
什么是最左字首原则？
MySQL中的索引可以以一定顺序引用多列，这种索引叫作联合索引。如User表的name和city加联合索引就是(name,city)，而最左字首原则指的是，如果查询的时候查询条件精确匹配索引的左边连续一列或几列，则此列就可以被用到。如下：
select * from user where name=xx and city=xx ; ／／可以命中索引
select * from user where name=xx ; // 可以命中索引
select * from user where city=xx ; // 无法命中索引
复制程式码
这里需要注意的是，查询的时候如果两个条件都用上了，但是顺序不同，如 city= xx and name ＝xx，那么现在的查询引擎会自动优化为匹配联合索引的顺序，这样是能够命中索引的。
由于最左字首原则，在建立联合索引时，索引字段的顺序需要考虑字段值去重之后的个数，较多的放前面。ORDER BY子句也遵循此规则。
注意避免冗余索引
冗余索引指的是索引的功能相同，能够命中就肯定能命中 ，那么 就是冗余索引如（name,city ）和（name ）这两个索引就是冗余索引，能够命中后者的查询肯定是能够命中前者的 在大多数情况下，都应该尽量扩充套件已有的索引而不是建立新索引。
MySQLS.7 版本后，可以通过查询 sys 库的 schema_redundant_indexes 表来检视冗余索引
Mysql如何为表字段新增索引？
1.新增PRIMARY KEY（主键索引）
ALTER TABLE `table_name` ADD PRIMARY KEY ( `column` )
复制程式码
2.新增UNIQUE(唯一索引)
ALTER TABLE `table_name` ADD UNIQUE ( `column` )
复制程式码
3.新增INDEX(普通索引)
ALTER TABLE `table_name` ADD INDEX index_name ( `column` )
复制程式码
4.新增FULLTEXT(全文索引)
ALTER TABLE `table_name` ADD FULLTEXT ( `column`)
复制程式码
5.新增多列索引
ALTER TABLE `table_name` ADD INDEX index_name ( `column1`, `column2`, `column3` )
复制程式码
储存引擎
一些常用命令
检视MySQL提供的所有储存引擎
mysql> show engines;
复制程式码
从上图我们可以查看出 MySQL 当前预设的储存引擎是InnoDB,并且在5.7版本所有的储存引擎中只有 InnoDB 是事务性储存引擎，也就是说只有 InnoDB 支援事务。
检视MySQL当前预设的储存引擎
我们也可以通过下面的命令检视预设的储存引擎。
mysql> show variables like '%storage_engine%';
复制程式码
查看表的储存引擎
show table status like "table_name" ;
复制程式码
MyISAM和InnoDB区别
MyISAM是MySQL的预设数据库引擎（5.5版之前）。虽然效能极佳，而且提供了大量的特性，包括全文索引、压缩、空间函式等，但MyISAM不支援事务和行级锁，而且最大的缺陷就是崩溃后无法安全恢复。不过，5.5版本之后，MySQL引入了InnoDB（事务性数据库引擎），MySQL 5.5版本后预设的储存引擎为InnoDB。
大多数时候我们使用的都是 InnoDB 储存引擎，但是在某些情况下使用 MyISAM 也是合适的比如读密集的情况下。（如果你不介意 MyISAM 崩溃回复问题的话）。
两者的对比：
是否支援行级锁 : MyISAM 只有表级锁(table-level locking)，而InnoDB 支援行级锁(row-level locking)和表级锁,预设为行级锁。是否支援事务和崩溃后的安全恢复： MyISAM 强调的是效能，每次查询具有原子性,其执行数度比InnoDB型别更快，但是不提供事务支援。但是InnoDB 提供事务支援事务，外部键等高阶数据库功能。 具有事务(commit)、回滚(rollback)和崩溃修复能力(crash recovery capabilities)的事务安全(transaction-safe (ACID compliant))型表。是否支援外来键： MyISAM不支援，而InnoDB支援。是否支援MVCC ：仅 InnoDB 支援。应对高并发事务, MVCC比单纯的加锁更高效;MVCC只在 READ COMMITTED 和 REPEATABLE READ 两个隔离级别下工作;MVCC可以使用 乐观(optimistic)锁 和 悲观(pessimistic)锁来实现;各数据库中MVCC实现并不统一。推荐阅读：MySQL-InnoDB-MVCC多版本并发控制......《MySQL高效能》上面有一句话这样写到:
不要轻易相信“MyISAM比InnoDB快”之类的经验之谈，这个结论往往不是绝对的。在很多我们已知场景中，InnoDB的速度都可以让MyISAM望尘莫及，尤其是用到了聚簇索引，或者需要访问的资料都可以放入内存的应用。
一般情况下我们选择 InnoDB 都是没有问题的，但是某事情况下你并不在乎可扩充套件能力和并发能力，也不需要事务支援，也不在乎崩溃后的安全恢复问题的话，选择MyISAM也是一个不错的选择。但是一般情况下，我们都是需要考虑到这些问题的。
乐观锁与悲观锁的区别
悲观锁
总是假设最坏的情况，每次去拿资料的时候都认为别人会修改，所以每次在拿资料的时候都会上锁，这样别人想拿这个资料就会阻塞直到它拿到锁（共享资源每次只给一个执行绪使用，其它执行绪阻塞，用完后再把资源转让给其它执行绪）。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。Java中synchronized和ReentrantLock等独占锁就是悲观锁思想的实现。
乐观锁
总是假设最好的情况，每次去拿资料的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个资料，可以使用版本号机制和CAS算法实现。乐观锁适用于多读的应用型别，这样可以提高吞吐量，像数据库提供的类似于write_condition机制，其实都是提供的乐观锁。在Java中java.util.concurrent.atomic包下面的原子变数类就是使用了乐观锁的一种实现方式CAS实现的。
两种锁的使用场景
从上面对两种锁的介绍，我们知道两种锁各有优缺点，不可认为一种好于另一种，像乐观锁适用于写比较少的情况下（多读场景），即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。但如果是多写的情况，一般会经常产生冲突，这就会导致上层应用会不断的进行retry，这样反倒是降低了效能，所以一般多写的场景下用悲观锁就比较合适。
乐观锁常见的两种实现方式
乐观锁一般会使用版本号机制或CAS算法实现。
1. 版本号机制
一般是在资料表中加上一个资料版本号version字段，表示资料被修改的次数，当资料被修改时，version值会加一。当执行绪A要更新资料值时，在读取资料的同时也会读取version值，在提交更新时，若刚才读取到的version值为当前数据库中的version值相等时才更新，否则重试更新操作，直到更新成功。
举一个简单的例子： 假设数据库中账户资讯表中有一个 version 字段，当前值为 1 ；而当前账户余额字段（ balance ）为 $100 。
操作员 A 此时将其读出（ version=1 ），并从其账户余额中扣除 $50（ $100-$50 ）。在操作员 A 操作的过程中，操作员B 也读入此使用者资讯（ version=1 ），并从其账户余额中扣除 $20 （ $100-$20 ）。操作员 A 完成了修改工作，将资料版本号加一（ version=2 ），连同账户扣除后余额（ balance=$50 ），提交至数据库更新，此时由于提交资料版本大于数据库记录当前版本，资料被更新，数据库记录 version 更新为 2 。操作员 B 完成了操作，也将版本号加一（ version=2 ）试图向数据库提交资料（ balance=$80 ），但此时比对数据库记录版本时发现，操作员 B 提交的资料版本号为 2 ，数据库记录当前版本也为 2 ，不满足 “ 提交版本必须大于记录当前版本才能执行更新 “ 的乐观锁策略，因此，操作员 B 的提交被驳回。这样，就避免了操作员 B 用基于 version=1 的旧资料修改的结果覆盖操作员A 的操作结果的可能。
2. CAS算法
即compare and swap（比较与交换），是一种有名的无锁算法。无锁程式设计，即不使用锁的情况下实现多执行绪之间的变数同步，也就是在没有执行绪被阻塞的情况下实现变数的同步，所以也叫非阻塞同步（Non-blocking Synchronization）。CAS算法涉及到三个算子
需要读写的内存值 V进行比较的值 A拟写入的新值 B当且仅当 V 的值等于 A时，CAS通过原子方式用新值B来更新V的值，否则不会执行任何操作（比较和替换是一个原子操作）。一般情况下是一个自旋操作，即不断的重试。
关于自旋锁，大家可以看一下这篇文章，非常不错：《 面试必备之深入理解自旋锁》
乐观锁的缺点
ABA 问题是乐观锁一个常见的问题
1 ABA 问题
如果一个变数V初次读取的时候是A值，并且在准备赋值的时候检查到它仍然是A值，那我们就能说明它的值没有被其他执行绪修改过了吗？很明显是不能的，因为在这段时间它的值可能被改为其他值，然后又改回A，那CAS操作就会误认为它从来没有被修改过。这个问题被称为CAS操作的 "ABA"问题。
JDK 1.5 以后的 AtomicStampedReference 类就提供了此种能力，其中的 compareAndSet 方法就是首先检查当前引用是否等于预期引用，并且当前标志是否等于预期标志，如果全部相等，则以原子方式将该引用和该标志的值设定为给定的更新值。
2 循环时间长开销大
自旋CAS（也就是不成功就一直循环执行直到成功）如果长时间不成功，会给CPU带来非常大的执行开销。 如果JVM能支援处理器提供的pause指令那么效率会有一定的提升，pause指令有两个作用，第一它可以延迟流水线执行指令（de-pipeline）,使CPU不会消耗过多的执行资源，延迟的时间取决于具体实现的版本，在一些处理器上延迟时间是零。第二它可以避免在退出循环的时候因内存顺序冲突（memory order violation）而引起CPU流水线被清空（CPU pipeline flush），从而提高CPU的执行效率。
3 只能保证一个共享变数的原子操作
CAS 只对单个共享变数有效，当操作涉及跨多个共享变数时 CAS 无效。但是从 JDK 1.5开始，提供了AtomicReference类来保证引用物件之间的原子性，你可以把多个变数放在一个物件里来进行 CAS 操作.所以我们可以使用锁或者利用AtomicReference类把多个共享变数合并成一个共享变数来操作。
锁机制与InnoDB锁算法
MyISAM和InnoDB储存引擎使用的锁：
MyISAM 采用表级锁(table-level locking)。InnoDB 支援行级锁(row-level locking)和表级锁,预设为行级锁表级锁和行级锁对比：
表级锁： Mysql中锁定 粒度最大 的一种锁，对当前操作的整张表加锁，实现简单，资源消耗也比较少，加锁快，不会出现死锁。其锁定粒度最大，触发锁冲突的概率最高，并发度最低，MyISAM和 InnoDB引擎都支援表级锁。行级锁： Mysql中锁定 粒度最小 的一种锁，只针对当前操作的行进行加锁。 行级锁能大大减少数据库操作的冲突。其加锁粒度最小，并发度高，但加锁的开销也最大，加锁慢，会出现死锁。详细内容可以参考： Mysql锁机制简单了解一下
InnoDB储存引擎的锁的算法有三种：
Record lock：单个行记录上的锁Gap lock：间隙锁，锁定一个范围，不包括记录本身Next-key lock：record+gap 锁定一个范围，包含记录本身相关知识点：
innodb对于行的查询使用next-key lockNext-locking keying为了解决Phantom Problem幻读问题当查询的索引含有唯一属性时，将next-key lock降级为record keyGap锁设计的目的是为了阻止多个事务将记录插入到同一范围内，而这会导致幻读问题的产生有两种方式显式关闭gap锁：（除了外来键约束和唯一性检查外，其余情况仅使用record lock） A. 将事务隔离级别设定为RC B. 将引数innodb_locks_unsafe_for_binlog设定为1大表优化
当MySQL单表记录数过大时，数据库的CRUD效能会明显下降，一些常见的优化措施如下：
1. 限定资料的范围
务必禁止不带任何限制资料范围条件的查询语句。比如：我们当用户在查询订单历史的时候，我们可以控制在一个月的范围内；
2. 读/写分离
经典的数据库拆分方案，主库负责写，从库负责读；
3. 垂直分割槽
根据数据库里面资料表的相关性进行拆分。 例如，使用者表中既有使用者的登入资讯又有使用者的基本资讯，可以将使用者表拆分成两个单独的表，甚至放到单独的库做分库。
简单来说垂直拆分是指资料表列的拆分，把一张列比较多的表拆分为多张表。 如下图所示，这样来说大家应该就更容易理解了。
垂直拆分的优点： 可以使得列资料变小，在查询时减少读取的Block数，减少I/O次数。此外，垂直分割槽可以简化表的结构，易于维护。垂直拆分的缺点： 主键会出现冗余，需要管理冗余列，并会引起Join操作，可以通过在应用层进行Join来解决。此外，垂直分割槽会让事务变得更加复杂；4. 水平分割槽
保持资料表结构不变，通过某种策略储存资料分片。这样每一片资料分散到不同的表或者库中，达到了分散式的目的。 水平拆分可以支撑非常大的资料量。
水平拆分是指资料表行的拆分，表的行数超过200万行时，就会变慢，这时可以把一张的表的资料拆成多张表来存放。举个例子：我们可以将使用者资讯表拆分成多个使用者资讯表，这样就可以避免单一表资料量过大对效能造成影响。
水平拆分可以支援非常大的资料量。需要注意的一点是：分表仅仅是解决了单一表资料过大的问题，但由于表的资料还是在同一台机器上，其实对于提升MySQL并发能力没有什么意义，所以 水平拆分最好分库 。
水平拆分能够 支援非常大的资料量储存，应用端改造也少，但 分片事务难以解决 ，跨节点Join效能较差，逻辑复杂。《Java工程师修炼之道》的作者推荐 尽量不要对资料进行分片，因为拆分会带来逻辑、部署、运维的各种复杂度 ，一般的资料表在优化得当的情况下支撑千万以下的资料量是没有太大问题的。如果实在要分片，尽量选择客户端分片架构，这样可以减少一次和中介软件的网络I/O。
下面补充一下数据库分片的两种常见方案：
客户端代理： 分片逻辑在应用端，封装在jar包中，通过修改或者封装JDBC层来实现。 当当网的 Sharding-JDBC 、阿里的TDDL是两种比较常用的实现。中介软件代理： 在应用和资料中间加了一个代理层。分片逻辑统一维护在中介软件服务中。 我们现在谈的 Mycat 、360的Atlas、网易的DDB等等都是这种架构的实现。关注作者：JAVA高阶程序员
我会不定期在微头条发放：（Java工程化、分散式架构、高并发、高效能、深入浅出、微服务架构、Spring、MyBatis、Netty、源代码分析）等技术学习资料，以及Java进阶学习路线图。
