mysql知识概要总结

持久性：

问题：数据误删（数据备份）、mysql崩溃（或断电）
**影响：**数据丢失、数据叶损坏
binlog——恢复数据
redolog——崩溃恢复
innodb——双写缓冲区、数据页（首尾校验）数据崩溃恢复时：会头尾校验不一致的时候用到双写恢复，否则用redolog恢复

顺序io：
分配数据页是按照区来分配，一区64页，一个区是物理上连续的页，保证了顺序io；
insert新增一个数据页面：
分配数据页是按照区来分配，一区64页，一个区是物理上连续的页，保证了顺序io；

缓存页：
free链表：
lru链表：解决预读&全表
flush链表：
读数据：
根据hash找到对应的数据页有没有在缓存，移除掉一个free链表的节点 & 在lru链表添加节点
写数据刷脏叶：
后台线程刷：从lru链表冷数据区，或者flush链表——双写机制，先写双写缓冲区，再写数据叶（双写可关闭）
.查数据：
1.1先找到bufferpool中找到数据页
怎么确定bufferpool中没有～bufferpool中对缓存页弄了个hash表
1.2怎么把数据页放到bufferpool中～
磁盘读出来之后从free链表中取一个控制块填入这个磁盘页信息
1.3自适应hash

1.3然后在数据页中二分查页里面的数据目录定位到数据。

hash表：

1. 表空间/页号～页：找到对应的数据页有没有在缓存

mysql性能优化的时候注意到锁的问题：
2. 架构调优：是否可以把不适合数
据库做的事情放到数据仓库、搜索引擎或者缓存中去做
3. MySQL调优：需要确认业务表结构设计是否合理，SQL语句优化是否足够，该添加的索引是否都添加了，是否可以剔除多余的索引等等

行锁&表锁
表锁开销小：因为直接找到这个表枷锁即可
行锁开销大的原因：要找到这一行加锁，有索引还好，没索引更麻烦；
可串行化：
连普通的select都会加锁

3undolog
3.1update数据
a不同的更新会产生不同的undo操作 比如定长字段 不定长字段 更新主键
b页面的重用

4redolog
4.1redolog解决的问题
4.2wal
4.3刷盘规则
44和binlog区别
4.5崩溃恢复机制：lsn 二段提交 binlog
4.6redo日志组

其他innodb概念

全表扫的时候 在叶子节点的段空间中扫。
删除的时候：数据记录的删除标志位设为1 并且移到垃圾链表并且可重用空间。

二mysql性能优化
设计层面
1.锁～锁不走索引会升级成表锁
注意update范围～间隙锁
注意锁的时间～本地事务
2.反范式设计
4.改变库表结构使用反范式

索引层面

.看看sql能不能用到索引合并
得索引等值匹配。
5.查看慢sql慢的原因是因为没有走索引还是因为在等待锁

7.成本计算
8.explain
11.索引失效：范围查询（in，or，大于），索引计算，like，最左原则
索引优化：

1. 分页查询
2. count
3. 3.索引的重复度，大小，索引不要冗余
4. orderby建立索引（否则走文件排序）
5. distinct建立索引否则（临时表）
6. 减少范围查询（成本计算可能失效）
7. 前缀索引，联合索引（失效问题）

其他：
联合索引——想到会order by 的话，得注意where是不是用到了联合索引，使用不当的话会走文件排序消耗性能
——想到会索引失效&成本计算，最左前最、like %，当然了范围查询也可能失效，不失效，涉及到成本计算
——建立索引的时候，重复低的排在前面
——覆盖索引
hash索引——innodb的自适应hash，
——以及其他也进行了hash优化，比如redo，崩溃恢复

不熟的点

redis

io多路——所以redis做了优化。