1. 事务

ACID 个性

• 原子性(Atomicity)：事务是一个不可分割的单位，因而在一个事务里的所有操作要么全副失效，要么全副不失效。
• 一致性(Consistency)：也能够了解为是预期状态的正确性，即从一个正确的状态到另一个正确的状态，这里的状态往往是由业务来定义的。比方转账中的一个扣钱一个加钱，是咱们规定的一个数据流转，那么执行前的账户余额和转账后的账户余额就得满足加减个性，这就是所谓的业务正确。
• 隔离性(Isolation)：事务并发执行时，各个事务之间相互影响的水平。
• 长久化(Durability)：通过日志等伎俩，只有咱们的事务提交胜利了，那么就意味着这次的数据操作是胜利的。即便下次重启了程序，也不会失落此处的操作后果。

隔离级别

• 未提交读： 即所谓的脏读，事务读取的数据可能是另一个事务已批改但还没提交的，这部分数据有可能产生回滚。导致后续的操作依赖了有效的数据。
• 已提交读： 如果想避免脏读，就须要期待其余事务提交后再进行读取操作。
• 可反复读： 已提交读的隔离级别思考到了数据回滚的有效性，却无奈阻止事务的屡次提交。比方事务 A 一直的对表进行批改提交，那么事务 B 就会在不同的工夫点读取到不同的数据。为了让事务 B 在执行期间读取的数据都是统一的，就有了可反复读的隔离级别，即事务 B 在执行期间，其余事务不得进行批改操作。
• 可串行化： 下面的可反复读隔离级别保障了事务执行期间读取的一致性。然而这里并不包含插入、删除操作。即会呈现读多读少数据的状况，这种景象叫做幻读。为了解决幻读，只得进行串行化执行事务，能力互不影响。而此时的事务并发性是最低的

2. 索引

Mysql 的索引分类

• 从数据结构划分： B+ 树、hash 索引、全文索引
• 从物理构造划分： 汇集索引、非汇集索引
• 从逻辑用户划分： 主键、惟一索引、复合索引、一般单列索引

汇集索引、非汇集索引、主建的区别

• 汇集索引：在索引的叶子节点间接存 data 数据, 应用的是物理排序，一个表只能有一个字段设置了汇集索引（因为物理排序规定只能有一个），容许有 null 的数据存在，数据也不肯定是惟一的。
• 主建：惟一标识某行记录，不容许有 null 的数据，要求数据必须惟一。在设置某个字段为主建时，数据库个别会主动在这个主建上建设一个惟一索引，并且如果之前表没有创立过汇集索引，还会在这个主建上建设一个汇集索引。
• 非汇集索引：索引的叶子节点存的是数据域的记录指针，须要跳转查找。排序规定是逻辑排序，因而能够有多个非汇集索引存在。

有哪些状况会让索引生效？

• 在 where 字段 上应用了函数或其余隐式转换
• Like 含糊查问，结尾应用了 “%”，例如 like ‘%hello%’
• where 条件里应用了 or
• 建设了复合索引，但 where 条件里应用的是第二个字段的搜寻

最左匹配准则是指？

mysql 建设联结索引后，是按最左匹配准则来筛选记录的，即检索数据是从联结索引的第一个字段来筛选的。如果 where 里的条件只有第二个字段，那么将无奈利用到索引。

索引的底层数据结构 B+ 树是怎么样的？

B+ 树是二叉搜寻树的一个裁减，是多路搜寻树。它只在叶子节点存储具体的数据或者数据的指向指针，而非叶子节点寄存索引数据。这样能够升高磁盘 IO，还能充分利用磁盘的预读性能，批量的加载索引数据。

b 树 b+ 树 b- 树的区别

• b 树就是 b- 树，国外叫 b-tree, 也就是 b 树。
• b-tree 是在非叶子节点寄存了数据，在查问索引时，只有找到索引值也就能够找到数据了，这样能够提前终止搜寻。但每个节点就得存储索引值 + 数据值，占用的页空间会比拟大，须要的磁盘 io 次数也会变多，即便是不须要关怀的数据也会被预加载进去，节约性能。
• b+ 树是将索引值存在非叶子节点，数据值存在叶子节点，这样能够压缩树的高度，缩小磁盘 io。

为什么不能在反复率高，例如 性别 字段上建设索引？

对于性别这种索引，因为反复率高，对于 B+ 树 (多路搜寻树) 来讲，得遍历多条门路，搜寻代价大。还不如全表扫描，这样不须要保护索引，升高开销。

Mysql 的 hash 索引是怎么样，有什么优缺点？

hash 索引将列通过 hash 运算失去 hash code，而后将 hash code 跟数据行的指针地址关联在一起，下次查找时只需查找对应 hash code 的数据行地址即可。

hash 索引十分的紧凑，查找速度很快，实用于内存存储引擎的利用。不过它只能准确查问，不反对范畴查找，也不能间接进行排序。限度还是挺多的。

Mysql 的全文索引

全文索引次要是用于文档查找，像咱们可能会从多篇文章中查找蕴含某些词语的文章，这时就能够应用全文索引了。尽管 like 也能够应用，然而效率太低了。全文索引在接管到文档时，会对它进行分词解决，以获取到关键词。而后会将关键词和属于这个文档的 id 关联起来。下次查找，就会先到关键词列表里找到关联的文档 id，最初利用文档 id 去查找到文档数据。

3. 日志

日志类别

• binlog： 二进制日志，记录了数据库对数据的批改记录，包含了 DDL：例如表的创立，数据更新等。但并不包含 select 这些查问语句。binlog 日志是属于逻辑语句的记录，可用于主从数据库的同步。
• relay log： 中继日志，用于主从备份复原应用的。有主服务器的 binlog 逻辑操作语句，以及以后的复原地位。
• 慢查问日志： 记录在 mysql 里执行工夫超过预期值的耗时语句
• redo log： redo log 是对加载到内存数据页的批改后果的记录，和 binlog 不同的是，binlog 记录的是逻辑操作语句，偏差于过程记录。而 redo log 是一个数据页的批改日志，偏差于后果的记录。
• undo log： 回滚日志次要用于回滚数据，和 redo log 不一样的是，undo log 是逻辑日志，是一种相同操作的记录，比方在回滚时，如果是 insert 操作时，则会逆向为 delete，delete 操作时，逆向为 insert 操作，更新则复原到过后的版本数据。

redo log 相干概念：writepos、checkpoint、prepare、commit

redo log 是用来记录以后数据页的批改状况，因为性能问题，每次批改并不会实时同步到硬盘。而是先在内存中批改，而后将批改状况记录到 redo 里，再定时的去将 redo 刷新到硬盘里。因而，redo log 有 2 个地位，一个是 writepos，本人写日志的地位；另一个是 checkpoint，是定时的将数据页同步到硬盘的地位。

redo log 在写 binlog 日志前会先记录 redo log，记录完后标记为 prepare 状态。当 binlog 也写入实现后，才将 redo log 标记为 commit 状态。只有当 redo log 是 commit 状态时，事务能力真正的 commit。这样能避免主从节点依据 binlog 同步有可能事务不统一的状况。

4. Mysql 里的锁

Mysql 里的锁有哪些？

乐观 / 乐观锁

• 乐观锁：在读取数据时会假如各个事务互不影响，它们会解决好属于本人的那局部数据。如果在更新数据时，发现有其余事务批改了属于本人的数据，则会回滚之前的所有操作。
• 乐观锁：采取了先获取锁再拜访的激进策略，如果曾经有其余事务获取了锁，则必须期待锁开释能力持续。

共享 / 排它锁

• 共享锁：又称读锁，以后事务在读取时，容许其余事务并发读取，但不容许其余事务上排它锁，必须等本人开释了能力持续。
• 排它锁：又称写锁，在写锁占有时，如果其余事务想上读写锁，则得排队期待。

表锁 / 行锁

• 表锁：在操作数据时，间接将整张表锁住，操作粒度很大，很容易让其余事务在期待，但不会产生死锁。
• 行锁：针对的是行记录的并发管制，锁粒度很细，能反对高并发，然而不排除会有死锁状况产生。在 mysql 里行锁依赖索引实现，如果没有索引存在，则会间接进行表锁！

行锁

• 记录锁：只锁住某一条记录。当对惟一索引 (包含主键) 进行准确查问时，会应用记录锁。
• 间隙锁：当应用范畴查问时，会对符合条件的区间数据上锁。在波及到一般索引（即不是惟一索引）的查问时，都会应用间隙锁。
• Next-key 锁：临建锁，能够了解为 记录锁 + 间隙锁。当对惟一索引进行范畴查找或对惟一索引进行查找但后果不存在时（能够了解为锁住不存在的记录），会应用临建锁。

下面的间隙锁、临建锁无效的避免了事务幻读状况产生，防止了在查找期间有数据新增或删除。

意向锁

表锁的一种，它仅仅示意一种操作动向。当咱们应用粒度比拟小的行锁时，在检测是否有锁时，须要一行一行的查看，效率较低。有了意向锁之后，则不需一行一行的排查，只需检测对应的意向锁即可。

事务里锁的利用是怎么样的？

可反复读

可反复读应用的是 MVCC 快照，所以在读取数据时大多数时候不须要应用锁。

但应用了 UPDATE, DELETE，或 SELECT with FOR UPDATE（排它锁）或 FOR SHARE（共享锁），则会依据上面的状况来应用锁：

• 在惟一索引上准确查找某条记录时，应用记录锁
• 对于其余的搜寻，InnoDB 将会锁定扫描到的索引范畴，应用间隙锁或临建锁来 避免幻读 的产生

读提交

也是应用 MVCC 机制来读取数据，不过在应用 UPDATE, DELETE，或 SELECT with FOR UPDATE（排它锁）或 FOR SHARE（共享锁）时和下面的机制不一样，当存储引擎将筛选到的记录交给 mysql server 层后，会对不相干的数据进行解锁，所以不会波及间隙锁或临建锁。它们只会在做外键束缚检查和反复键查看时应用到。因为间隙锁的禁用，可能会 呈现幻读 景象。

未提交读

在 mysql 的 innodb 存储引擎里做 SELECT操作不会做任何锁动作，如果是 myisam 存储引擎，则会上共享锁。
如果应用 UPDATE, DELETE，或 SELECT with FOR UPDATE（排它锁）或 FOR SHARE（共享锁） 则和读提交一样的准则。

可序列化读

可序列化读在应用 select 时，个别会主动的转化为 SELECT … FOR SHARE（共享锁），以保障读写序列化。

lock in share mode 和 for update 里间隙锁什么时候会利用？

• lock in share mode, for update 如果 where 条件是非索引类的，则不会加间隙锁；
• lock in share mode, for update 如果 where 条件是主键类的，并且找不到记录时会加间隙锁；如果找到记录了则会将间隙锁给开释了。比方 where 主键 = 3 能找到记录时则不会加间隙锁，找不到时会在该数据的前后叶子节点间加间隙锁；此时如果记录里只有 1，8，9，则会在 1, 8 之间加间隙锁
• lock in share mode, for update 如果 where 条件是非汇集索引类的，会加间隙锁，即便找不到记录。

锁超时的配置

当 mysql 获取锁超时时候，如果零碎变量 innodb_rollback_on_timeout 为 off , 则以后事务只会回滚最初一条 sql, 所以倡议设置 innodb_rollback_on_timeout 为 on, 这样在获取锁超时时能够回滚全副 sql。

5. MVCC 是指什么？

MVCC 即 多版本并发管制，它利用了 undo log 会在数据批改时保留上一个批改记录指针的特点，使得每个事务对数据的批改能有本人的历史版本追溯，就像镜像备份一样。当进行读操作时，如果有其余写操作的事务并发进行，那么此时能够依据事务的隔离级别抉择读取最新版本亦或本人之前版本的数据。MVCC 不须要加锁的，它能进步事务的并发解决能力。

6. mysql 的复制技术

• 全同步复制：只有等所有的 slave 节点将同步的日志写入 relay log，并且响应 ack 确认后，此次的事务才会提交。数据完整性高，但性能低
• 半同步复制：只有有一个 salve 节点响应 ack 后就能够认为同步胜利，但细分为了两种，一种是 AFTER_COMMIT：先在主库提交事务, 而后同步从库, 期待从库的 ack 确认. 才通知客户端是否 Ok。另一种是 AFTER_SYNC：主库先不提交事务, 只有从库 有 replay log , 回复了 ack 后才进行提交事务。前面一种数据一致性较高
• 异步复制：一旦有须要复制的就告诉 slave, 但不会期待确认胜利才进行后续操作。

7. 存储引擎

Mysql 存储引擎有哪些以及特点？

• InnoDB： 它是 mysql 的默认存储引擎，可能实现 ACID 个性的事务，并且能提交、回滚、复原数据，能很好的保障用户数据。同时反对了行级锁、汇集索引以及外键束缚，是一个欠缺的存储引擎。
• MyISAM： 是 mysql 最开始的存储引擎，占用空间小，能疾速存储，但不反对事务，提供了基于表级别的锁粒度，实用于配置或只读性能的应用程序。
• Memory： 数据都是存在内存里的，能提供快速访问，不过应该较少人应用，毕竟一旦断电数据也就失落了。
• CSV： 带有逗号分隔值的文本文件，没有索引存在。然而兼容性很好，能够跟其余的程序替换数据。

myisam 存储引擎和 innodb 的区别

• innoDB 反对事务，myisam 不反对
• innoDB 反对行锁，myisam 不反对，只能到表锁
• innoDB 反对外键，myisam 不反对
• innoDB 不反对全文索引，myisam 反对
• innoDB 反对汇集索引 和 非汇集索引；myISAM 只反对非汇集索引，该索引存的是数据域的记录指针，还得跳转查找。

8. Mysql 的三层架构

• 连贯层： 次要负责连接池、通信协议、认证受权等；
• SQL 层： 这一层是 mysql 的大脑，通过一系列组件失去数据操作的最优解。
• 存储层： 负责数据的存储、检索。
  

9. 执行打算是什么？怎么看？

执行打算是 mysql 依据咱们的查问语句进行一系列的剖析后失去的优化计划。咱们能够通过执行打算来获取执行过程。

执行打算的获取：

explain select 语句

波及的字段含意如下：

• id：该 SELECT 标识符
• select_type：该 SELECT 类型
• table：输入行的表
• partitions：匹配的分区
• type：联接类型
• possible_keys：可供选择的可能索引
• key：理论抉择的索引
• key_len：所选密钥的长度
• ref：与索引比拟的列
• rows：预计要查看的行数
• filtered：按表条件过滤的行百分比
• Extra：附加信息

其中，有个 type 字段，它的含意大略如下：

• eq_ref：应用到了 UNIQUE 或 PRIMARY KEY 索引
• ref：显示索引的哪一列被应用了
• ref_or_null：对 Null 进行了索引优化
• range：索引范畴检索
• index：索引扫描
• unique_subquery：应用了 in 子查问，外面波及了主键字段
• index_subquery：应用了 in 子查问，外面波及了非惟一索引
• fulltext：全文索引
• all：全表扫描数据

从下面大略就能剖析出索引的应用状况了，如果是 all，那就是没有用到索引了。

10. SQL 注入的景象是？

在拼接 SQL 语句时，间接应用客户端传递过去的值拼接，如果客户端传来蕴含 or 1=1 相似的语句，那么就会筛选到非预期的后果，进而达到坑骗服务器的成果。

解决方案是应用当初数据库提供的预编译（prepare）和查问参数绑定性能，例如应用占位符 ?，而后将带有占位符的 SQL 语句交给数据库编译，这样数据库就能晓得要执行的是哪些语句，条件值又是哪些，而不会混淆在一起。

11. UNION 和 UNION ALL 的区别？

• UNION ALL：将所有的数据联结起来，即便有反复数据
• UNION：会合并反复数据

12. 为什么尽量应用自增 ID，而不是 UUID？

自增 ID 是由有序的，而 UUID 是无序的，如果该字段作为索引，那么就会很容易突破 B+ 树的均衡，进而一直的在进行磁盘数据页的调整，导致性能降落

13. 分库分表有哪些？有什么优缺点？

• 分库：从业务角度进行切分
• 分表：将数据依据肯定的规定落在多张表上。比方按工夫范畴来切分，或者通过对 ID 进行 Hash 来路由到对应的表上。

分库分表后使得数据不再集中到一张表上，但也带来了保护以及其余解决问题。比方原来的事务变为分布式事务；原来的 join 操作将要变为在应用层序做过滤；还有数据的后续迁徙、扩容布局等。

14. 内连贯、外连贯区别

• 内连贯：只有符合条件的记录才会呈现在后果集里
• 外连贯：其后果集中不仅蕴含合乎连贯条件的行，还会包含左表、右表或两个表中的所有数据行，这三种状况顺次称之为左外连贯，右外连贯，和全外连贯。

15. 常见的数据库优化

• 对经常出现在 where 条件里，并且数据反复率不高的字段建设索引
• 应用 JOIN 来代替子查问；
• 能应用 in 就不应用 or，前者能命中索引，后者会让索引生效
• 防止在 where 字段上计算，例如 where a / 3 = 1，这样会让索引生效；防止在 where 字段上应用 NULL 值的判断

• 关上慢查问日志配置，有针对性的剖析响应迟缓的语句。

  ---

  感兴趣的敌人能够搜一搜公众号「阅新技术」，关注更多的推送文章。
  能够的话，就顺便点个赞、留个言、分享下，感激各位反对！
  阅新技术，浏览更多的新常识。