mysql基础
数据库面试要点：关于MySQL数据库千万级数据查询和存储 - 知乎 (zhihu.com)
必须了解的mysql三大日志-binlog、redo log和undo log - 知乎 (zhihu.com)
MYSQL | 最左匹配原则的原理 - 云+社区 - 腾讯云 (tencent.com)
https://www.cnblogs.com/rollenholt/p/3776923.html
https://juejin.cn/post/6844903967365791752
连接与管理
每个客户端连接都会在服务器进程中拥有一个线程，每个连接的查询都会在这个单独的线程中执行，该线程只能轮流在某个cpu核心或者cpu中运行。服务器会负责缓存线程，因此不需要为每一个新建的连接创建或者销毁线程
优化与执行
mysql会解析查询，并创建内部数据结构，然后对其进行各种优化，包括重写查询，决定表的读取顺序，以及选择合适的索引等
并发控制
读写锁，共享锁和排他所。
写锁会阻塞其他的写锁和读锁
写锁
锁粒度，一种提高共享资源并发性的方式就是让锁定的对象更具有选择性。加锁是需要消耗资源，锁的各种操作获得释放等都会增加锁的开销。锁策略，平衡开销和数据的安全性之间寻求平衡
表锁
行级锁 最大程度的支持并发处理
事务 原子性 一致性 隔离性 持久性
原子性 一个事务必须被视为一个不可分割的最小工作单元，整个事务的所有操作要么全部提交成功，要么全部失败回滚
隔离性 事务之间互相是不可见的
持久性 一旦事务提交 修改会永久保存到数据库中 及时系统崩溃 修改的数据也不会丢失。
一致性 修改只要存在一个没有成功 事务所做的修改也不会保存到数据库中
什么是事务的隔离级别？MySQL的默认隔离级别是什么？
为了达到事务的四大特性，数据库定义了4种不同的事务隔离级别，由低到高依次为Read uncommitted、Read committed、Repeatable read、Serializable，这四个级别可以逐个解决脏读、不可重复读、幻读这几类问题。
SQL 标准定义了四个隔离级别：
READ-UNCOMMITTED(读取未提交)： 最低的隔离级别，允许读取尚未提交的数据变更，可能会导致脏读、幻读或不可重复读。
READ-COMMITTED(读取已提交)： 允许读取并发事务已经提交的数据，可以阻止脏读，但是幻读或不可重复读仍有可能发生。
REPEATABLE-READ(可重复读)： 对同一字段的多次读取结果都是一致的，除非数据是被本身事务自己所修改，可以阻止脏读和不可重复读，但幻读仍有可能发生。
SERIALIZABLE(可串行化)： 最高的隔离级别，完全服从ACID的隔离级别。所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。
Mysql 默认采用的 REPEATABLE_READ隔离级别 Oracle 默认采用的 READ_COMMITTED隔离级别
死锁
死锁是指两个或者多个事务在同一个资源上互相占用，并请求锁定对方占用的资源 从而导致恶性循环的现象。当多个事务同时锁定同一个资源时，也会产生死锁
解决方案 数据库实现了各种死锁检测和死锁超时机制，查询的时间达到锁等待超时的设定后放弃锁的请求
选择优化的数据类型
数据类型简单越好 尽量避免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+树使得范围查找，排序查找，分组查找以及去重查找变得异常简单。
乐观锁悲观锁
什么是乐观锁，什么是悲观锁 - 简书 (jianshu.com)
分库分表相关
(1 封私信 / 32 条消息) 什么是分库分表，为什么要分库分表？ - 知乎 (zhihu.com)
(1 封私信 / 32 条消息) 什么是分库分表，为什么要分库分表？ - 知乎 (zhihu.com)
MySQL 分库分表方案，总结的非常好！ - 妖星杉木 - 博客园 (cnblogs.com)
按照锁的粒度分数据库锁有哪些？
- 行级锁:行级锁是Mysql中锁定粒度最细的一种锁，表示只针对当前操作的行进行加锁。行级锁能大大减少数据库操作的冲突。其加锁粒度最小，但加锁的开销也最大。行级锁分为共享锁 和 排他锁。特点：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。
- 表级锁: 表级锁是MySQL中锁定粒度最大的一种锁，表示对当前操作的整张表加锁，它实现简单，资源消耗较少，被大部分MySQL引擎支持。最常使用的MYISAM与INNODB都支持表级锁定。表级锁定分为表共享读锁（共享锁）与表独占写锁（排他锁）。特点：开销小，加锁快；不会出现死锁；锁定粒度大，发出锁冲突的概率最高，并发度最低。
- 页级锁:页级锁是MySQL中锁定粒度介于行级锁和表级锁中间的一种锁。表级锁速度快，但冲突多，行级冲突少，但速度慢。所以取了折衷的页级，一次锁定相邻的一组记录。
从锁的类别上分MySQL都有哪些锁呢？
从锁的类别上来讲，有共享锁和排他锁。共享锁: 又叫做读锁。 当用户要进行数据的读取时，对数据加上共享锁。共享锁可以同时加上多个。排他锁: 又叫做写锁。 当用户要进行数据的写入时，对数据加上排他锁。排他锁只可以加一个，他和其他的排他锁，共享锁都相斥。
InnoDB存储引擎的锁的算法有哪三种？
- Record lock：单个行记录上的锁
- Gap lock：间隙锁，锁定一个范围，不包括记录本身
- Next-key lock：record+gap 锁定一个范围，包含记录本身
什么是死锁？怎么解决？
死锁是指两个或多个事务在同一资源上相互占用，并请求锁定对方的资源，从而导致恶性循环的现象。
常见的解决死锁的方法如果不同程序会并发存取多个表，尽量约定以相同的顺序访问表，可以大大降低死锁机会。在同一个事务中，尽可能做到一次锁定所需要的所有资源，减少死锁产生概率；对于非常容易产生死锁的业务部分，可以尝试使用升级锁定颗粒度，通过表级锁定来减少死锁产生的概率；
如果业务处理不好可以用分布式事务锁或者使用乐观锁
数据库的乐观锁和悲观锁是什么？怎么实现的？
数据库管理系统（DBMS）中的并发控制的任务是确保在多个事务同时存取数据库中同一数据时不破坏事务的隔离性和统一性以及数据库的统一性。乐观并发控制（乐观锁）和悲观并发控制（悲观锁）是并发控制主要采用的技术手段。
悲观说：假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作。在查询完数据的时候就把事务锁起来，直到提交事务。实现方式：使用数据库中的锁机制
乐观锁：假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性。在修改数据的时候把事务锁起来，通过version的方式来进行锁定。实现方式：乐一般会使用版本号机制或CAS算法实现。
