阿里P8整理Mysql面试题答案，助你“脱颖而出”，吊打面试官！（建议收藏） - 知乎 (zhihu.com)
最全MySQL面试60题和答案 - 知乎 (zhihu.com)
MySQL 分库分表方案，总结的非常好！ - 妖星杉木 - 博客园 (cnblogs.com)
连接与管理
每个客户端连接都会在服务器进程中拥有一个线程，每个连接的查询都会在这个单独的线程中执行，该线程只能轮流在某个cpu核心或者cpu中运行。服务器会负责缓存线程，因此不需要为每一个新建的连接创建或者销毁线程
优化与执行
mysql会解析查询，并创建内部数据结构，然后对其进行各种优化，包括重写查询，决定表的读取顺序，以及选择合适的索引等
并发控制
读写锁，共享锁和排他所。
写锁会阻塞其他的写锁和读锁
写锁
锁粒度，一种提高共享资源并发性的方式就是让锁定的对象更具有选择性。加锁是需要消耗资源，锁的各种操作获得释放等都会增加锁的开销。锁策略，平衡开销和数据的安全性之间寻求平衡
表锁
行级锁 最大程度的支持并发处理
事务 原子性 一致性 隔离性 持久性
原子性 一个事务必须被视为一个不可分割的最小工作单元，整个事务的所有操作要么全部提交成功，要么全部失败回滚
隔离性 事务之间互相是不可见的
持久性 一旦事务提交 修改会永久保存到数据库中 及时系统崩溃 修改的数据也不会丢失。
一致性 修改只要存在一个没有成功 事务所做的修改也不会保存到数据库中
死锁
死锁是指两个或者多个事务在同一个资源上互相占用，并请求锁定对方占用的资源 从而导致恶性循环的现象。当多个事务同时锁定同一个资源时，也会产生死锁
解决方案 数据库实现了各种死锁检测和死锁超时机制，查询的时间达到锁等待超时的设定后放弃锁的请求
选择优化的数据类型
数据类型简单越好 尽量避免NULL
索引的类型
B-Tree索引 不再需要进行全表扫描获取需要的数据
哈希索引 基于哈希表实现
R-Tree
索引大大减少了服务器需要扫描的数据量
索引可以帮助服务器避免排序和临时表
索引可以将随机I/O变为顺序IO
查询性能优化
查询优化 索引优化 库表结构优化
慢查询基础：优化数据访问
1确认应用程序是否存在检索大量超过需要的数据。
2确认mysql服务器层是否存在分析大量超过需要的数据行
3mysql是否存在扫描额外的记录
a 响应时间 扫描的行数 返回的行数
重构查询的方式
一个复杂的查询还是多个简单查询‘
切分查询
分解关联查询
索引合并优化
等值传递
并行执行
哈希关联
松散索引扫描
最大值和最小值优化
优化特定类型的查询
优化count查询
优化关联查询
优化子查询
优化group by和distinct
优化limit分页
那为什么不是B树而是B+树呢？
我们在这里重新回顾一下 MySQL 默认的存储引擎选择 B+ 树而不是哈希或者 B 树的原因：
- 哈希虽然能够提供
O(1)的单数据行操作性能，但是对于范围查询和排序却无法很好地支持，最终导致全表扫描； - B 树能够在非叶节点中存储数据，但是这也导致在查询连续数据时可能会带来更多的随机 I/O，而 B+ 树的所有叶节点可以通过指针相互连接，能够减少顺序遍历时产生的额外随机 I/O；
为什么 MySQL 使用 B+ 树 - 面向信仰编程 (draveness.me)
mysql聚簇索引和非聚簇索引的区别 - 刘指导 - 博客园 (cnblogs.com)
MySql聚簇索引与非聚簇索引的区别 - 张兵帅 - 博客园 (cnblogs.com)
MySQL 中存储引擎的主要作用是负责数据的存储和提取，除了 InnoDB 之外，MySQL 中也支持 MyISAM 作为表的底层存储引擎。
首先需要澄清的一点是，MySQL 跟 B+ 树没有直接的关系，真正与 B+ 树有关系的是 MySQL 的默认存储引擎 InnoDB，MySQL 中存储引擎的主要作用是负责数据的存储和提取，除了 InnoDB 之外，MySQL 中也支持 MyISAM 作为表的底层存储引擎。
如果我们使用哈希作为底层的数据结构，遇到上述的场景时，使用哈希构成的主键索引或者辅助索引可能就没有办法快速处理了，它对于处理范围查询或者排序性能会非常差，只能进行全表扫描并依次判断是否满足条件。全表扫描对于数据库来说是一个非常糟糕的结果，这其实也就意味着我们使用的数据结构对于这些查询没有其他任何效果，最终的性能可能都不如从日志中顺序进行匹配。
使用 B+ 树其实能够保证数据按照键的顺序进行存储，也就是相邻的所有数据其实都是按照自然顺序排列的，使用哈希却无法达到这样的效果，因为哈希函数的目的就是让数据尽可能被分散到不同的桶中进行存储，所以在遇到可能存在相同键 author = 'draven 或者排序以及范围查询 comments_count > 10 时，由哈希作为底层数据结构的表可能就会面对数据库查询的噩梦 —— 全表扫描。
B 树和 B+ 树在数据结构上其实有一些类似，它们都可以按照某些顺序对索引中的内容进行遍历，对于排序和范围查询等操作，B 树和 B+ 树相比于哈希会带来更好的性能，当然如果索引建立不够好或者 SQL 查询非常复杂，依然会导致全表扫描。
与 B 树和 B+ 树相比，哈希作为底层的数据结构的表能够以 O(1) 的速度处理单个数据行的增删改查，但是面对范围查询或者排序时就会导致全表扫描的结果，而 B 树和 B+ 树虽然在单数据行的增删查改上需要 O(log n) 的时间，但是它会将索引列相近的数据按顺序存储，所以能够避免全表扫描。
- 1）B+树非叶子节点上是不存储数据的，仅存储键值，而B树节点中不仅存储键值，也会存储数据。innodb中页的默认大小是16KB，如果不存储数据，那么就会存储更多的键值，相应的树的阶数（节点的子节点树）就会更大，树就会更矮更胖，如此一来我们查找数据进行磁盘的IO次数有会再次减少，数据查询的效率也会更快。
- 2）B+树索引的所有数据均存储在叶子节点，而且数据是按照顺序排列的，链表连着的。那么B+树使得范围查找，排序查找，分组查找以及去重查找变得异常简单。