MySQL 几大部分：存储引擎、索引、事务、锁
MySQL的MyISAM和InnoDB存储引擎的区别是啥？
myisam，不支持事务，不支持外键约束，索引文件和数据文件分开，这样在内存里可以缓存更多的索引，对查询的性能会更好，适用于那种少量的插入，大量查询的场景。
innodb，主要特点就是支持事务，走聚簇索引，强制要求有主键，支持外键约束，高并发、大数据量、高可用等相关成熟的数据库架构，分库分表、读写分离、主备切换，全部都可以基于innodb存储引擎。
聊聊MySQL的索引实现原理？各种索引你们平时都怎么用的？
- MySQL索引的原理和数据结构能介绍一下吗？
- b+树和b-树有什么区别？
- Myisam和Innodb存储引擎的索引实现？
- MySQL聚簇索引和非聚簇索引的区别是什么？
- 他们分别是如何存储的？
- 使用MySQL索引都有哪些原则？
- MySQL复合索引如何使用？
先说什么索引？
索引就是用一个数据结构组织某一个列数据，然后根据这一列数据查询时，不用全表扫描，根据特定数据结构找到那一列的值，然后找到对应行的物理地址。
先说b-树，画图如下：
查找时，从根节点开始二分查找。
b+树是b-树的变形，不一样的地方：
B-和B+树区别：
1. B+树只有叶子节点存储数据，其他中间节点只有索引没有数据，同样的大小的磁盘页可以容纳更多的节点元素。相同数量下，B+树更“矮胖”，查询IO次数更少。
2. B+树查询必须查找叶子节点，B+树查询更稳定(并不慢)。B-树查询性能不稳定，最好只查根节点，最坏查到叶子节点。
3. B+树范围查询更简便。B+树中序遍历要简单得多。
Myisam和Innodb存储引擎的索引实现？
myisam的索引中，每个叶子节点的data存放的是数据行的物理地址，每行对应一个物理地址。数据文件单独存放一个文件。最大特点是数据文件和索引文件是分开的。
innodb的数据文件本身就是索引文件，必须有主键，会根据主键建立一个默认索引，叫聚簇索引。
innodb下，对某个非主键字段创建索引，那么最后那个叶子节点的值就是主键的值，再用主键的值到聚簇索引里查找到数据，叫回表。
innodb，建议统一用auto_increment自增值作为主键，可以保持聚簇索引直接加记录，不用修改原来b+树的结构，浪费时间。
索引常见使用规则？
比如product表，创建索引：
create index (shop_id, product_id, gmt_create)
1. 全列匹配
where条件正好用到这3个字段，就用到联合索引。
2. 最左前缀匹配
SQL里，正好用到联合索引最左边的一个或几个列表。
3. 最左前缀匹配，但中间某个值没有匹配
如果sql用了联合索引第一列和第三列，会按照第一列在索引里找，找完后对结果集根据第三列做全表扫描，不会走第三列的索引了。
4. 前缀匹配
如果不是等值，或比如=, >, <=等操作，而是Like操作。则只有Like ‘xx%’ (%在最后)这种才能用上索引。
5. 范围匹配
只有符号最左前缀的列的范围才用到索引，范围之后的列用不到索引。
比如: select * from product where shop_id >= 1 and product_id = 1；
这里就只用到shop_id索引。
6. 包含函数
对某个列用了函数，则该列不走索引。
索引缺点以及使用注意？
常见缺点：增加磁盘消耗，占用磁盘文件，同时高并发频繁插入和修改索引，会导致性能损耗。
使用注意：1. 尽量创建少的索引，一个表，两三个。
2. 一个字段的值几乎都不太一样的，比如id，这样用索引效果最好。
小结：
互联网系统中，一般尽量降低SQL复杂度，用简单的主键索引(聚簇索引)+少数联合索引，
可以覆盖一个表的所有SQL查询，更复杂的业务逻辑，应该放在Java代码里实现。
SQL越简单，后面迁移，分库分表，读写分离的成本更低，减少对SQL的改造。
MySQL最好用在在线及时存储，不要用于计算(Join, 子查询，函数等等)。高并发场景下，计算放在Java内存里。
说说事务的几个特性是啥？有哪几种隔离级别？
特性：ACid
原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)
隔离级别：
1. 读未提交
事务A把id=1, name=张三修改为李四，但是还未提交，这时事务B已经看到id=1的name为李四了。
2. 读已提交（不可重复读）
事务A把id=1, name=张三修改为李四，但是还未提交。事务B第一次读，读到是张三，看不见李四。
紧接着事务A提交了事务，事务A在第二次读的时候，读到的是修改后的李四。
这个也叫不可重复读，就是所谓一个事务内对一个数据的两次读，可能读到不一样的值。
3. 可重复读
无论事务A什么时候把张三修改为李四，事务B不管什么时刻读到值，都是事务B刚开启时读到的值。事务开启后对一行读取的值都是一样的。
幻读（不是隔离级别）：事务A第一次查询所有数据，就一行id=1。后面事务Ｂ插入一行数据id=2，事务Ａ查询时发现2条数据，感觉发生幻觉。
针对数据件数发生变化。
4. 串行化
事务A运行期间，事务Ｂ不允许运行。事务Ａ提交完事务后，事务Ｂ才开始运行。串行化是为了解决幻读。
MySQL是怎么实现可重复读的？
MySQL是通过MVCC机制来实现的，就是多版本并发控制（Multi-Version Concurrency Control)。
Innodb存储引擎会在每行数据最后增加两个隐藏列，
一个保证行的创建时间，一个保存行的删除时间，但这里存放的不是时间，是事务id，事务id是mysql自己维护的自增，全局唯一。
举例1：
id name 创建事务id 删除事务id
1 张三 101 空
事务id=101的事务查询id=1的这一行，一定能找到创建事务id<=当前事务id的一行。
当事务id=102把id=1的一行删除了，这时id=1的行的删除事务id设置为102．
id name 创建事务id 删除事务id
1 张三 101 102
事务id=101的事务，再次查询id=1的行，仍然能查到。因为创建事务id<=当前事务id，且当前事务id＜删掉事务id。
举例2：（同一行被修改）
id name 创建事务id 删除事务id
2 李四 201 空
2 王五 202 空
事务201创建了id=2的数据，事务202修改了id=2的数据，把name修改为王五，这时候事务201仍然可以查询到创建事务id<=当前事务id的数据，
查不到比自己创建事务id大的记录。
MySQL就是通过MVCC实现可重复读，事务可以读取该事务启动时创建事务id的记录，读不到后面事务的版本。
说说MySQL数据库锁的实现原理吗？如果死锁了咋办？
数据库锁有哪些类型？锁如何实现的？MySQL行级锁有哪两种？一定会锁指定行吗？为什么？
悲观锁和乐观锁是什么？使用场景是什么?
MySQL的死锁原理以及如何定位和解决？
1. MySQL锁
锁类型：表锁、行锁和页锁。
myisam一般加表锁，查询时，默认加共享锁，也就是表读锁，别人可以查，但不能写；
myisam写的时候，加表独占锁，也就是表写锁，别人不能读也不能写。现在用的很少。
innodb的行锁分共享锁(S)和排他锁(X)。
共享锁，多个事务可以加共享锁读同一行数据，但别的事务不能写这行数据；
排他锁，一个事务可以写这行数据，别的事务只能读不能写。
innodb表锁，分成意向共享锁，就是加共享行锁的时候，必须先加这个共享表锁；
还有一个意向排他锁，给某行加排他锁的时候，必须先给表加排他锁。这个表锁，是innodb引擎自动加的。
insert、update、delete时，innodb会自动为这一行加行级的排他锁。
select时，innodb啥锁都不加，默认实现可重复读，MVCC机制，所有多个事务随便读一个数据，不会有冲突，大家读的是自己的快照，不涉及锁。
手动加共享锁：
select * from table where id=1 lock in share mode; //id=1这行加了共享锁，其他事务不能修改
手动加排他锁（悲观锁）：
select * from table where id=1 for update; //id=1这行加了排他锁，表示该事务准备修改，其他事务被卡住等待。慎用！线上一般不用，容易出问题。
乐观锁：
select id, name, version from table where id = 1; update table set name=’new name’, version = version + 1 where id = 1 and version = 1;
每次修改比较这条数据和之前查出的数据版本号是否一致，一致就修改并且版本号+1，否则就不更新。
乐观锁可以提高并发访问的效率，但是如果出现了冲突只能向上抛出，然后重来一遍；悲观锁可以避免冲突的发生，但是会降低效率。
高并发场景用乐观锁!
死锁：
事务A，B对自己的资源持有锁的同时，又要去请求对方持有的锁，结果谁也拿不到锁，导致死锁。
死锁排查，查看死锁日志，找到对应的sql，找到代码，具体判断为什么死锁。
MySQL的SQL调优一般都有哪些手段？你们一般怎么做？
1. SQL慢，一般就是没有用索引。看执行计划，有没有走索引。
explain select * from table table|type|possible_keys|key|key_len|ref|rows|extra
table: 哪个表
type: 类型 all:全部扫描 const:读常量，最多一条记录匹配 eq_ref:走主键，一般最多一条记录 index:扫描全部索引 range: 扫描部分索引 possible_keys: 显示可能使用的索引
key: 实际使用的索引
key_len: 使用索引的长度
ref: 联合索引哪一列被用到
rows: 一共扫描和返回了多少行
extra: using filesort:需要额外进行排序, using temporary: mysql构建了临时表，比如排序的时候 using where:就是对索引扫描出来的数据再次根据where来过滤出结果
参考资料：
互联网Java工程师面试突击（第三季）-- 中华石杉
原文地址：https://www.cnblogs.com/fyql/p/12362351.html