MySql项目中使用的存储引擎
5.0之前默认存储引擎为MyISAM引擎
-
索引只有一种，被索引的字段值作为索引数据，叶子节点还包含该记录数据页地址
-
不支持事务
-
没有undo log 和redo log
-
仅支持表🔒
-
不支持外键
-
优势：执行增删改会保存表的总行数
5.0之后默认存储引擎为InnoDB
-
索引支
-
聚簇索引：主键值作为索引数据，叶子节点还包了所有字段数据。!
-
非聚簇索引：被索引的字段值作为索引数据，叶子节点还包含了主键值
-
- 如果要查询的数据在非聚簇索引中没有，再通过主键值进行聚簇索引查询
- 事务
- 通过undo log（撤销日志文件）支持事务回滚，当前读（多版本查询）实现原子性
- 通过redo log（重做日志文件）实现持久性
- 通过两阶段提交实现一致性
- 通过当前读，🔒实现隔离性
- 🔒
- 行🔒
- 间隙🔒
- 表级🔒
- 支持外键
数据库的三大范式
第一范式：原子性：保证数据不可再分
第二范式：在满足第一范式下，每张表只描述一件事情，就是主键对应着所有信息
第三范式：满足第一二范式的情况下，保证表中的数据的主键直接相关，而不是间接相关
ACID
A：原子性：在一个事务中，所有操作要么全部完成，要么全部不完成，不可结束在中间某个环节。
C：一致性：事务在开始之前和事务结束以后，数据库的完整性没有被破环。
I：隔离性：数据库允许多个并发数位同时对其数据进行读写和修改能力。
D：持久性：事务处理结束后，对数据的修改就是永久的，即使系统故障也不会丢失，即持久化存在于硬盘中。
事务隔离级别有哪些？MySQL的默认隔离级别是
未提交读
- 脏读：读出的数据无效（可能是其他事务修改后未提交的数据）
- 解决方案：提高隔离级别
提交读RC
- 不可重复读：两次读出的数据不一致（两次操作中间，其他线程执行了修改）
- 解决方案：提供隔离级别
可重复度RR（mysql的默认级别）
- 幻读：读后进行插入操作，可能主键冲突（两次操作汇总，其他线程进行了新增操作）
- 解决方案：加锁避免：for update（间隙🔒），其他线程执行新增时，会被间隙锁阻塞，如何该线程会出现主键冲突。
串行化（影响性能，基本上不用）
- 无错误现象，读写都会阻塞其他事务，可以保证更强的一致性。
B+树与B树的区别，为什么Mysql使用B+树
B树的特点
-
其实本质就是n叉数，分叉多意味着节点的中的孩子（key）多，树的高度就降低了
-
查询时不会出现主键重复，因为每一个key中都会有value!
-
在等值查询中，可能会查到非叶子节点就查到了，完成查询
B+树的特点
-
在B树索引的基础上，索引中仅存放key，这样能进一步增加分叉树，假设key占13字节，那么一页数据分叉树可以到1260，树高可以进一步下降为2
-
可能会存在键的重复，B+树普通节点存放key，叶子节点才存放key+value!
-
在执行等值查询时，都需要查询叶子节点才能查到key和value
使用B+树的原因
数据都是放在了叶子节点，检索的效率比较稳定，非叶子节点最仅存放key，没存放数据，所有非叶子节点能存放key的数量就比较多，树的层级就比较低，所有检索的效率就比较高而稳定。
- mysql索引使用的是B+树，因为索引是用来加快查询的，而B+树通过对数据进行排序，提高了查询效率
- 通过一个节点中可以存储多个元素，从而可以使B+树的高度不会太高
- 在mysql中InnerDB默认为16kb，索引一般情况下一颗两层的B+树可以存2000万左右的数据
- 叶子节点之间有指针，更适合磁盘数据的索引，而MySQL主要针对的就是磁盘数据，且支持等值查询，可以很好的支持全表扫描，范围查询等sql语句。
并发事务带来的问题
- 脏读：读取到了未提交的数据
- 丢失更新：两事务同时对一个字段进行+10，最终结果只进行了+10
- 不可重复读：原来是A的，现在变成B了
- 幻读：原来不存在的，现在存在了
什么字段上不适合建立索引
- 大字段，文本字段，test，blog
- 查询频率比较低的
- 离散度比较低的，如性别
建立了索引的同时也占用了磁盘空间，并且在执行增删改时会产生索引维护
记录价格应该使用什么字段
DECIMAL：Decimal是专门为财务相关问题设计的数据类型，它实际上是以字符串的形式存放的，可在定义时划定整数部分以及小数部分的位数；在对精度要求比较高时（如货币、科学数据），用DECIMAL类型比较好。
如何定位执行效率低的SQL语句
使用慢查询，或者日志查询，这个慢看怎么定义，有对应的变量long_query_time：是指执行超过多久的SQL会被日志记录下来。
找到慢查询SQL后，优化流程是
思路
- 首先检查sql语句是否有问题，如子查询可以改为关联查询
- 有没有用到某个索引？如果没有用，是否需要添加索引？
- 有没有由于什么情况导致索引失效？
列举几个索引失效的场景
- %like,模糊查询like中加了前%
- 在列中进行了函数运算（注意，在值中函数运算不会失效）
- 没有遵循最左前缀原则
- 当两类型需要转换后比较，（本质是列上引用转换函数，导致索引失效）
- 使用 <> 、not in 、not exist、!=
- 字符型字段为数字时在where条件里不添加引号
- 当变量采用的是times变量，而表的字段采用的是date变量时.或相反情况。
聚簇索引和非聚簇索引
- 聚簇索引：主键值作为索引数据，叶子节点还包了所有字段数据。
- 非聚簇索引（二级索引）：被索引的字段值作为索引数据，叶子节点还包含了主键值
如果要查询的数据在非聚簇索引中没有，再通过主键值进行聚簇索引查询数据
什么是索引的覆盖 什么是回表
- 索引覆盖：是一种为了避免回表查询的优化策略。索引上的内容也不过是将表上的某些字段以B+树的结构储存起来，如果我们要查询的字段刚好就是索引包括的字段，那就可以在扫描完索引后直接得到结果，不需要回表，这就是覆盖索引
- 回表：先查询非聚簇索引找到主键id，再通过主键查找聚簇索引进而查找到数据，这个过程走了两次索引，就叫回表。
所有在写sql语句时，我们可以尽可能避免select *的出现。
什么是索引条件下推
索引下推(Index Condition Pushdown，简称ICP)，是MySQL5.6版本的新特性，它能减少回表查询次数，提高查询效率。
索引条件下推其实就是将部分服务层（Server层）负责的事情，交给了下层（引擎层）去处理。
在没有使用ICP的情况下，MySQL的查询：
- 存储引擎读取索引记录；
- 根据索引中的主键值，定位并读取完整的行记录（回表）；
- 存储引擎把记录交给服务层去检测该记录是否满足Where条件。
使用ICP的情况下，查询过程：
- 存储引擎读取索引；
- 判断WHERE条件部分能否用索引中的列来做检查
- 条件不满足，处理下一行记录（丢弃，减少回表次数）；
- 条件满足，用索引中的主键去定位并读取完整的行记录（回表）；
- 存储引擎把记录交给服务层，服务层检测该记录是否满足WHERE条件的其余部分。
子查询与连接查询哪一个快？为什么？
连接查询较快
- 子查询需要建立临时表去存储子查询查询的数据
- 引用了子查询的条件不能使用索引下推
大批量数据插入时比较慢咋优化？列出两点即可
- 数据库在保存数据时，尽量保证插入时id有序
- 尽量保证批量插入在同一个事务中进行
- 关闭唯一性校验（前提是能保证插入的数据唯一）
MySql的索引原理
索引：随着查询效率被优化，增删改操作效率一定会被影响，哈希索引就是增删改效率最高的。
其实索引的本质就是一种排好序的数据结构。形象的说，可以看作字典中的目录。
索引并不只有B树和B+树
- 哈希索引
- 理想时间复杂度为O（1）
- 适用场景：适用于等值查询的场景，内存数据的索引
- 典型实现：Redis，MySQL的memory引擎
- 平衡二叉树（二叉树中特殊）
- 查询和更新的时间复杂度都是O（log（n））以2为底
- 适用场景：内存数据的索引，当不适合磁盘数据的索引，可以认为树的高度决定了磁盘I/O的次数，百万数据高度约为20
- 树高公式log（1000000）/log（2）
- BTree索引
-
其实就是n叉数，分叉多意味着节点中的孩子（key）多，树的高度就降低了
-
分叉数由页大小和行（key+value）大小决定
- 假设页大小为16k，每行40字节，那么分叉数就为16k/40=410
- 而分叉为410，则按百万数据树高约为3，仅3次I/O就能找到所需数据
- 假设页大小为16k，每行40字节，那么分叉数就为16k/40=410
-
局部性原理：每次I/O按页为单位读取数据，把多个key相邻的行放在同一页中（每页就是树上一个节点，能进一步减少I/O）
-
查询时不会出现主键重复，每一个key中都会有value!
-
遍历时要用中序遍历，会在叶子节点和非叶子节点来回，会降低性能
-
在等值查询时，可能 会查到非叶子节点就查到了，完成查询
-
- B+树索引
-
在BTree索引的基础上，索引中仅存放key，这样能进一步增加分叉数，假设key占13个字节，那么一页数据分叉数可以到1260，树高可以进一步下降为2
-
可能会存在键的重复，B+树普通节点存放key，叶子节点才存放key+value
-
采用链表连接，可以方便范围查询和全表遍历
-
在执行等值查询时，都需要查询叶子节点才能查到key和value
-
