导图社区 mysql
- 33
- 1
- 0
- 举报
mysql
This is a mind map about mysql，Main content: 数据库备份与恢复，主从复制，日志，MVVC，锁，事务，数据库的调优策略，数据库设计，索引。
编辑于2025-03-12 22:52:14- mysql
- 数据库设计
- 相似推荐
- 大纲
mysql
索引
索引的概述
为什么使用索引
减少磁盘I/O的次数，加快查询速率
索引的定义
索引是帮助MySQL高效获取数据的数据结构
索引优缺点
优点
降低数据库的IO成本
保证数据的唯一性
加速表和表之间的连接
减少查询中分组和排序的时间
缺点
创建和维护索引耗费时间
索引需要占磁盘空间
降低更新表的速度
索引的数据结构
B+树
我们用到的B+树都不会超过4层
常见的索引概念
聚簇索引
一般只有主键为唯一的聚簇索引
是一种数据存储方式
也就是索引即数据，数据即索引
优点
数据访问更快
对于主键的排序查找和范围查找速度非常快
节省了大量的IO操作
缺点
插入速度严重依赖插入顺序
一般都会定义一个自增的ID列为主键
更新主键的代价很高
一般都定义主键不可更新
二级索引访问需要两次索引查找
限制
只有InnoDB数据引擎支持聚簇索引
每个mysql表只能有一个聚簇索引
一般情况下就是该表的主键
如果没有定义主键，InnoDb会选择非空的唯一索引代替。
如果没有这样的索引，InnoDB会隐式的定义一个主键来作为聚簇索引
InnoDB表的主键尽量选用有序的顺序id，而不建议用无序的id，比如UUID、MD5、HASH、字符串列作为主键无法保证数据的顺序增长
二级索引
辅助索引
非聚簇索引
根据其他列再建一棵B+树
然后根据主键去聚簇索引回表查询
区别
聚簇索引的叶子节点存储的就是我们的数据记录，非聚簇索引的叶子节点存储的是数据位置。非聚簇索引不会影响数据表的物理存储顺序
一个表只能有一个聚簇索引，因为只能有一种排序存储的方式，但可以有多个非聚簇索引
使用聚簇索引，数据查询效率高，对数据进行插入，删除，更新等操作，效率会比非聚簇索引低
联合索引
以多列的大小为排序规则建立的B+树称为联合索引，本质上也是一个二级
InnoDB的B+树索引的注意事项
根页面位置万年不动
内节点中目录项记录的唯一性
一个页面最少存储2条记录
MyISAM的索引方案
非聚簇索引
叶子节点存的数据地址
MyISAM与InnoDB对比
MyISAM的索引方式都是非聚簇的，与InnoDB包含一个聚簇索引是不同的。
索引的代价
空间上的代价
时间上的代价
索引数据结构选择的合理性
Hash
二叉搜索树
AVL树
二叉平衡搜索树
B树
多路平衡查找树
叶子和非叶子都存放数据
B+树
思考题
差异
R树
索引的底层
InnoDB数据存储结构
页
默认大小为16KB
数据库管理存储空间的基本单位是页
页和页之间不在物理结构上相连，通过双向链表相关联
每个页中的记录会按照主键值从小到大的顺序组成一个单向链表
每个页都会生成页目录，通过二分查找法查找数据
页的内部结构
第一部分
文件头
文件尾
第二部分
空闲空间
用户记录
最小最大记录
第三部分
页目录
页面头部
行格式
COMPACT
变长字段长度列表
NULL值列表
记录头信息
delete_mask
min_rec_mask
record_type
heap_no
n_owned
next_record
记录的真实数据
row_id
transaction_od
roll_pointer
其他自定义列
Dynamic和Compressed行格式
行溢出
Redundant行格式
字段长度偏移列表
记录头信息
为什么要有区
为什么要有段
为什么要有碎片区
区的分类
空闲的区
有剩余空间的碎片区
没有剩余空间的碎片区
附属于某个段的区
表空间
表空间可以看做是InnoDB存储引擎逻辑结构的最高层
表空间是一个逻辑容器，表空间存储的对象是段，在一个表空间中可以有一个或多个段，但是一个段只能属于一个表空间。
表空间数据库有一个或多个表空间组成
从管理上可以划分为
系统表空间
独立表空间
撤销表空间
临时表空间
索引的创建与设计原则
索引的分类
功能逻辑
普通索引
唯一索引
主键索引
全文索引
物理实现方式
聚簇索引
非聚簇索引
作用字段个数
单列索引
联合索引
索引的查看
SHOW INDEX FROM TABLE_NAME
索引的创建
1. CREATE TABLE
隐式的
2.显示的创建
普通索引
唯一索引
声明有唯一索引的字段，在添加数据时，要保证唯一性，但是可以添加null
主键索引
只有隐式的方式创建
通过删除主键约束的方式删除主键索引
AlTER TABLE book2 DROP PRIMARY KEY
联合索引
全文索引
只有在CHAR、VARCHAR和TEXT的类型添加全文索引
索引的删除
方式一
方式二
MySQL8.0索引新特性
1. 支持降序索引
2. 隐藏索引
作用
创建
索引的设计原则
适合创建索引
字段的数值有唯一性的限制
频繁作为WHERE查询条件的字段
经常GROUP BY和ORDER BY的列
UPDATE、DELETE的WHERE的条件列
DISTINCT字段需要创建索引
多表JOIN连接操作时，创建索引注意事项
连接表的数量尽量不要超过3张
对WHERE条件创建索引
对于连接的字段创建索引
使用列的类型小的创建索引
使用字符串前缀创建索引
区分度高（散列性高）的列适合作为索引
使用最频繁的列放到联合索引的左侧
在多个字段都要创建索引的情况下，联合索引优于单值索引
限制索引的数目
建议单张表索引数量不超过6个
每个索引需要占用磁盘空间
索引会影响INSERT、DELETE、UPDATE等语句的性能
不适合创建索引
在WHERE中使用不到的字段，不要设置索引
数据量小的表最好不要使用索引
有大量重复数据的列上不要建立索引
避免对经常更新的表创建过多的索引
不建议用无序的值作为索引
删除不再使用或者很少使用的索引
不要定义冗余或重复的索引
性能分析工具的使用
慢查询日志
开启/关闭慢查询
slow_query_log=OFF/ON
设置慢查询时间门槛
设置慢查询日志文件输出
mysql慢查询日志分析工具
mysqldumpslow
删除慢查询日志
查看SQL执行成本
SHOW PROFILE
开启
set profiling = 'ON'
使用
最近一次查询
show profiles
show profile cpu,block io for query 3
常用参数
注意
分析查询语句：EXPLAIN
概述
基本语法
EXPLAIN各列的作用
table
表名
查询的每一行记录都对应着一个单表
id
在一个大的查询语句中每个SELECT关键字都对应一个唯一的id
注意
Union会去重
会创建临时表进行去重
结果会有三个id
UNION ALL
不去重
只有两个id
select_type
SELECT关键字对应的那个查询的类型，确定小查询在整个大查询中扮演了一个什么角色
值
SIMPLE
查询语句中不包含‘UNION’或者子查询的查询都算作是‘SIMPLE’类型
PRIMAYRY
UNION
UNION RESULT
SUBQUERY
在 MySQL 中，相关子查询（Correlated Subquery） 是指子查询依赖于外部查询的结果，每次子查询执行时都会参考外部查询的当前行。这与普通的子查询不同，普通子查询可以独立执行，而相关子查询必须在外部查询的上下文中运行。
DEPENDENT SUBQUERY
DEPENDENT UNION
DERIVED
MATERIALIZED
paritions
type
概述
值
system
const
eq_ref
ref
ref_or_null
index_merge
unique_subquery
range
index
all
possible_keys和key
possible_key
可能用到的索引
越少越好
key
实际上使用的索引
key_len
实际使用到的索引长度（即：字节数）
主要针对联合索引，有一定的参考意义
帮你检查‘是否充分的利用上了索引’
对比相同的索引，越大越好
ref
rows
预估的需要读取的记录条数
值越小越好
filtered
某个表经过搜索条件过滤后剩余记录条数的百分比
Extra
概述
值
No table used
当查询语句中没有‘FROM’子句时将会提示该额外信息
Impossible WHERE
查询语句的‘WHERE’子句永远为‘FALSE’时将会提示该额外信息
Using where
No matching min/max row
Using index
当我们的查询列表以及搜索条件中只包含属于某个索引的列，也就是在可以使用覆盖索引的情况下，在~Extr~列将会提示该额外信息。比方说下边这个查询中只需要用到`idx key1`而不需要回表操作：
Using index condition
索引条件下推
Using join buffer
Using union
Zero limit
Using filesort
Using temporary
EXPLAIN的进一步的使用
EXPLAIN四种输出格式
传统格式
JSON格式
会有查询执行成本信息
query_cost
cost_info
read_cost
IO成本
检测rows * （1-filter）条记录的cpu成本
eval_cost
检测rows * filter条记录的成本
prefix_cost
单独查询s1表的成本
read_cost + eval_cost
data_read_per_join
表示在此次查询中需要读取的数据量
使用
EXPLAIN FORMAT=JSON SELECT……
TREE格式
可视化输出
分析优化器执行计划：trace
概述
MySQL监控分析视图-sys schema
索引情况
表相关
语句相关
IO相关
InnoDB相关
索引优化与查询优化
概述
数据库调优纬度
索引失效，没有充分利用到索引
索引建立
关联查询太多JOIN（设计缺陷或不得已的需求）
SQL优化
服务器调优及各个参数设置（缓冲、线程数等）
调整my.cnf
数据过多
分库分表
分为物理查询优化和逻辑查询优化
物理查询优化
通过索引和表连接方式等技术进行优化
逻辑查询优化
通过SQL等价变换提升查询效率
索引失效案例
SQL语句是否使用索引，跟数据库版本、数据量、数据选择度都有关系
11条规则
全值匹配我最爱
联合索引全值匹配
最佳左前缀法则
结论：MySQL可以为多个字段创建索引，一个索引可以包括16个字段。对于多列索引，过滤条件要使用索引必须按照索引建立时的顺序，依次满足，一旦跳过某个字段，素引后面的字段都无法被使用。如果查询条件中没有使用这些字段中第1个字段时，多列（或联合）索引不会被使用。
主键插入顺序
插入时最好主键是依次增大的
计算、函数、类型转换（自动或手动）导致索引失效
类型转换导致索引失效
范围条件右边的列索引失效
不等于(!= 或者<>)索引失效
IS NULL可以使用索引， IS NOT NULL无法使用索引
LIKE以通配符%开头索引失效
or 前后存在非索引的列，索引失效
数据库和表的字符集一定要统一使用utf8mb4
一般性建议
各类的优化
关联查询优化
左外连接
内连接
JOIN语句原理
驱动表和被驱动表
Simple Nested-Loop Join（简单嵌套循环连接）
Index Nested-Loop Join（索引嵌套循环连接）
Block Nested-Loop-Join（块嵌套循环连接）
JOIN小结
整体效率比较
INLJ>BNLJ>SNLJ
HASH JOIN
子查询优化
子查询是MySQL的一项重要的功能，可以帮助我们通过一个SQL语句实现比较复杂的查询。但是，子查询的执行效率不高
原因
在MySQL中，可以使用连接（JOIN）查询来替代子查询
连接查询不需要建立临时表，其速度比子查询要快，如果查询中使用索引的话，性能就会更好
排序优化
引言
优化建议
案例
小结
filesort算法：双路排序和单路排序
双路排序
单路排序
结论及引申出的问题
优化策略
GROUP BY优化
group by使用索引的原测几乎跟order by-一致，group by即使没有过滤条件用到索引，也可以直接使用索引。
group by先排序再分组，遵照索引建的最佳左前缀法则
当无法使用索引列，增大max_length_for_sort_data和sort_buffer_size参数的设置
where效率高于having,能写在wherel限定的条件就不要写在having中了
减少使用order by,和业务沟通能不排序就不排序，或将排序放到程序端去做。Order by、group by、distinct这些语句较为耗费CPU,数据库的CPU资源是极其宝贵的。
包含了order by、group by、distincti这些查询的语句，where条件过滤出来的结果集请保持在1000行以内，否则SQL会很慢。
优化分页查询
优先考虑覆盖索引
什么是覆盖索引
案例
举例1
举例2
利弊
好处
弊端
索引（条件）下推
概述
ICP的开启/关闭
默认情况下启用索引条件下推
可以通过设置系统变量optimizer_switch控制index_condition_pushdown
使用条件
其它查询优化策略
EXISTS和IN的区分
引出
COUNT(*)与COUNT(具体字段)效率
关于SELECT(*)
LIMIT 1对优化的影响
多使用COMMIT
淘宝数据库，主键如何设计的
自增ID的问题
可靠性不高
存在自增ID回溯问题，MySQL8.0才修复
安全性不高
对外暴露的接口可以非常容易猜测对应的信息
性能差
自增ID的性能较差，需要在数据库服务器端生成
交互多
局部唯一性
业务字段做主键
淘宝的主键设计
推荐的主键设计
非核心业务
对应表的主键自增ID，如告警、日志、监控等信息
核心业务
主键设计至少应该是全局唯一且是单调递增的
最简单的一种主键设计：UUID
数据库设计
数据库的设计规范
为什么需要数据库设计
范式
概述
在关系型数据库中，关于数据表设计的基本原则、规则就称为范式
相关的名词概念
超键
能唯一标识元组的属性集叫做超键
候选键
如果超键不包括多余的属性，那么这个超键就是候选键
主键
用户可以从候选键中选择一个作为主键
外键
如果数据表R1中的某个属性集不是R1的主键，而是另一个数据表R2的主键，那么这个属性集就是数据表R1的外键
主属性
包含在任一候选键中的属性称为主属性
非主属性
与主属性相对，指的是不包含在任何一个候选键中的属性
包括（从上到下，由低到高）
第一范式
第一范式主要是确保数据表中每个字段的值必须具有原子性，也就是说数据表中每个字段的值为不可再次拆分的最小数据单元
第二范式
第二范式要求，在满足第一范式的基础上，还要满足数据表里的每一条数据记录，都是可唯一标识的。而且所有非主键字段，都必须完全依赖主键，不能只依赖主键的一部分。如果知道主键的所有属性的值，就可以检索到任何元组（行）的任何属性的任何值。（要求中的主键，其实可以拓展替换为候选键）。
第三范式
第三范式是在第二范式的基础上，确保数据表中的每一个非主键字段都和主键字段直接相关，也就是说，要求数据表中的所有非主键字段不能依赖于其他非主键字段
小结
范式的优点
数据的标准化有助于消除数据库中的数据冗余，第三范式通常被认为在性能、扩展性和数据完整性方面达到了最好的平衡
范式的缺点
范式的使用，可能降低查询效率。因为范式等级越高，设计出来的数据表就越多、越精细，数据的冗余度就越低，进行数据查询的时候就可能需要关联多张表，这不但代价昂贵，也可能使一些索引策略无效。
巴斯-科德范式
第四范式
多值依赖的概念
第五范式（完美范式）
反范式
概述
规范化VS性能
反范式的新问题
存储空间变大了
一个表中字段做了修改，另一个表中冗余的字段也需要做同步修改，否则数据不一致
若采用存储过程来支持数据的更新、删除等额外操作，如果更新频繁，会非常消耗系统资源
在数据量小的情况下，反范式不能体现性能的优势，可能还会让数据库的设计更加复杂
反范式的使用场景
当冗余信息有价值或者能大幅度提高查询效率的时候，我们才会采取反范式的优化
ER模型
概述
三要素
实体
概述
实体，可以看做是数据对象，往往对应于现实生活中的真实存在的个体。
在ER模型中，用矩形来表示
分为
强实体
不依赖于其他实体的实体
弱实体
对另一个实体有很强的依赖关系的实体
属性
指实体的特性
用椭圆形表示
关系
指实体之间的联系
用菱形来表示
概要
可以独立存在的是实体，不可再分的是属性
关系的类型
一对一
一对多
多对多
ER模型图转换成数据表
一个实体转换成一个数据表
一个多对多的关系转换成一个数据表
通过外键来表达1对多的关系
把属性转换成表的字段
数据表的设计原则
数据表的个数越少越好
数据表的字段个数越少越好
数据表中联合主键的字段个数越少越好
使用主键和外键越多越好
数据库对象编写建议
关于库
关于表、列
强制
建议
关于索引
SQL编写
数据库的调优策略
数据库调优的措施
调优的目标
吞吐量更大
尽可能节省系统资源，以便系统可以提供更大负荷的服务
响应速度更快
合理的结构设计和参数调整，以提高用户操作响应的速度
减少系统的瓶颈，提高MySQL数据库整体的性能
如何定位调优问题
用户的反馈（主要）
日志分析（主要）
服务器资源使用监控
数据库内部状况的监控
其他
调优的维度和步骤
第1步：选择适合的DBMS
第2步：优化表设计
第3步：优化逻辑查询
第4步：优化物理查询
第5步：使用Redis或Memcached作为缓存
第6步：库级优化
概述
1. 读写分离
2. 数据分片
MySQL服务器的优化
优化服务器硬件
配置较大的内存
配置高速磁盘系统
合理分布磁盘I/O
配置多处理器
优化MySQL的参数
优化数据库结构
概述
措施
拆分表：冷热数据分离
增加中间表
增加冗余字段
反范式
优化数据类型
优化插入记录的速度
1. MyISAM引擎的表
2. InnoDB引擎的表
使用非空约束
分析表、检查表与优化表
分析表
检查表
优化表
小结
大表优化
限制查询的范围
禁止不带任何限制数据范围条件的查询语句
读写分离
一主一从模式
双主双从模式
垂直拆分
水平拆分
其它调优策略
事务
事务概述
事务的状态
活动的
部分提交的
失败的
中止的
提交的
事务的ACID特性
原子性（atomicity）
事务是 不可分割的最小单位，要么全部执行成功，要么全部执行失败，不会出现部分执行的情况。
一致性（consistency）
事务的执行不会破坏数据库的完整性约束（如主键约束、外键约束、唯一性约束等）。
事务的执行前后，数据的状态必须符合业务规则（例如银行转账，钱不会凭空消失或增加）。
如果事务中某个操作导致数据库进入不一致状态，则整个事务回滚，保证数据库仍然保持一致性。
隔离性（isolation）
多个事务并发执行时，彼此之间不会相互影响，保证数据一致性。
持久性（durability）
事务一旦提交，数据永久保存，即使数据库崩溃、服务器断电，数据也不会丢失。
事务的使用
事务的完成过程
步骤1:开启事务
步骤2:一系列的DML操作
步骤3:结束的状态
提交的状态（COMMIT）
中止的状态（ROLLBACK）
事务的具体使用
显式事务
开启
start transaction
后面可以跟
read only
read write（默认）
with consistent snapshot
1、2可以和3单独联合
begin
savepiont
设置保存点
提交
commit
回滚
rollback
隐式事务
关键字
autocommit
set autocommit = true
每条DML都会自动提交
使用start transaction或begin开启事务，那么DML操作不会自动提交
隐式提交数据的情况
DDL
隐式使用或修改mysql数据库中的表
事务控制或关于锁定的语句
加载数据的语句
关于MySQL复制的一些语句
其它的一些语句
事务隔离级别
数据的并发问题
脏写
一个事务修改了另一个未提交事务修改过的数据，那就意味着反生了脏写
因为后者可能会发生回滚
脏读
一个事务读取了被另一个事务更新但没有提交的字段，若后者回滚，前者读取的内容就是临时且无效的
不可重复读
对于两个事务，一个事务读取了一个字段，另一个更新了该字段，之后前者再次读取同一个字段，值就不同了。意味着发生了不可重复读。
幻读
对于两个事务，一个事务从一个表中读取了一个字段，然后另一个事务在表中插入了一些新的行。之后，如果前者再次读取同一个表，就会多出了几行。那就意味着反生了幻读。
删除了几行不属于幻读
SQL中的四种隔离级别
READ-UNCOMMITED
读未提交
未提交的时候可以读
不会出现脏写的情况
会出现脏读的情况
READ-COMMITED
读已提交
已提交之后才可以读
解决出现脏读的问题
但会出现不可重复读的情况
REPEATABLE-READ
可重复读
两次读的结果一样
解决了不可重复读的情况
但会出现幻读的情况
SERIALIZABLE
串行化·
会解决幻读情况
总结
严重程度
脏写问题太严重了，哪种隔离级别都不会出现脏写的问题
MySQL事务日志
概述
事务有四种特性：原子性、一致性、隔离性和持久性
事务的隔离性是由锁机制实现的
而事务的原子性、一致性和持久性由事务的redo日志和undo日志来保证
redo日志（REDO LOG）
概述
REDO LOG称为重做日志，提供再写入操作，提供再写入操作，恢复提交事务修改的页操作，用来保证事务的持久性
是存储引擎层（innodb）生成的日志，记录的是“物理级别”上的页修改操作，比如页号xxx、偏移量yyy写入了zzz数据。主要为了保证数据的可靠性
优点
redo日志降低了刷盘频率
redo日志占用的空间非常小
存储表空间ID、页号、偏移量以及需要更新的值，所需的存储空间是很小的，刷盘快
特点
redo日志是顺序写入磁盘的
事务执行过程中，redo log不断记录
组成
重做日志的缓冲
保存在内存中，是易失的
通过参数innodb_log_buffer_size设置，默认16M，最大值是4096M，最小值为1M
重做日志文件
保存在硬盘中，是持久的
整体工作流程
redo log的刷盘策略
innodb_flush_log_at_trx_commit
设置为0
默认每隔一秒将redo log缓存刷到硬盘中
设置为1
每次提交都将redo log缓存刷到硬盘中
设置为2
将redo log缓存刷到文件系统缓存中，由操作系统控制什么时候写入硬盘中
写入redo log buffer过程
Mini-Transaction
redo log file
相关参数设置
日志文件组
check point
小结
undo日志（UNDO LOG）
概述
概念
UNDO LOG称为回滚日志，回滚行记录到某个特定版本，用来保证事务的原子性、一致性
是存储引擎层（innodb）生成的日志，记录的是逻辑操作日志，比如对某一行数据进行了INSERT语句操作，那么UNDO LOG就记录一条与之相反的DELETE操作。主要用于事务的回滚（UNDO LOG记录的是每个修改操作的逆操作）和一致性非锁定读（UNDO LOG回滚记录到某种特定版本——MVCC，即多版本并发控制）。
理解
作用
作用1: 回滚数据
作用2: MVCC
存储结构
回滚段与undo页
回滚段与事务
回滚段中的数据分类
undo log的类型
insert undo log
update undo log
undo 的生命周期
简要生成过程
详细生成过程
undo log的回滚
undo log的删除
事务的常见分类
锁
概述
MySQL并发事务访问相同记录
3种不同的情况
读-读情况
写-写情况
读-写情况或写-读情况
并发问题的解决方案
解决什么问题
脏读、不可重复读或幻读
方案一：读操作利用多版本并发控制（MVCC），写操作进行加锁
方案二：读、写操作都采用加锁的方式
对比
锁的分类
从数据操作的类型划分
概述
读锁/共享锁
对于读取的记录加S锁
对于读取的记录加X锁
写锁/排他锁
分类
INSERT
DELETE
UPDATE
情况一
未修改该记录的键值，并且被更新的列占用的存储空间在修改前后未发生变化
情况二
未修改该记录的键值，并且至少有一个被更新的列占用的存储空间在修改前后发生变化
情况三
修改了该记录的键值
则相当于在原记录做DELETE操作之后再来一次INSERT操作，加锁操作就需要按照DELETE和INSERT的规则进行了
锁粒度划分
概述
表级锁
概述
表级别的S锁、X锁
概述
使用方法
总结
意向锁（intention lock）
概述
意向锁要解决的问题
概括
意向共享锁
意向排他锁
总结
自增锁
插入模式
Simple Inserts（简单插入）
Bulk Inserts（批量插入）
Mixed-mode Inserts（混合插入）
解决办法
innodb_autoinc_lock_mode
设置为0（“传统”锁定模式）
设置为1（“连续”锁定模式）
设置为2（“交错”锁定模式）
MDL锁（元数据锁）
行级锁
概述
记录锁（Record Locks）
间隙锁（Gap Locks）
概念
作用
解决幻读的问题
间隙锁可能会导致死锁的问题
临键锁（Next-Key Locks）
插入意向锁（Insert Intention Locks）
页级锁
页锁
对待锁的态度划分
悲观锁
乐观锁
概念
实现机制
乐观锁的版本号机制
乐观锁的时间戳机制
两种锁的适用场景
加锁方式
隐式锁
显示锁
其他
全局锁
死锁
概念
两个事务都持有对方需要的锁，并且在等待对方释放，并且对方都不会释放自己的锁
产生死锁的条件
如何处理死锁
方式一
等待，直到超时，可以通过innodb_lock_wait_timeout来设置，例如innodb_lock_wait_timeout=50s
方式二
使用死锁检测进行死锁处理
如何避免死锁
锁的内存结构
概述
组成
锁所在的事务信息
索引信息
表锁/行锁信息
type_mode
其他信息
一堆比特位
锁监控
MVVC
概述
隔离级别
隐藏字段、Undo Log版本链
快照读与当前读
概述
快照读
当前读
MVCC实现原理之ReadView
ReadView
概念
设计思路
规则
MVCC整体操作流程
不同的隔离级别会有不同的处理方式
读已提交
一个事务中的每一个SELECT查询都会重新获取一次Read View
可重复读
总结
日志
概述
日志类型
概述
分别为
日志的弊端
通用查询日志
概述
查看参数
开启通用查询日志
查看日志
关闭通用查询日志
删除\刷新日志
错误日志
概述
开启
查看
删除&刷新
MySQL8.0新特性
小结
binlog
概述
日志参数设置
方式一：永久
方式二：临时
查看日志
使用日志恢复数据
根据pos恢复日志
第一步：查看
第二步：恢复
根据时间
第一步：查看
使用mysqlbinlog命令
第二步：恢复
二进制日志的删除
概述
其他场景
写入机制
概述
流程
binlog与redolog对比
两阶段提交
主从复制
子主题
中继日志
概述
查看中继日志
恢复的典型错误
主从复制
概述
如何提升数据库并发能力
主从复制的作用
主从复制的原理
原理剖析
三个线程
复制三步骤
复制的最大问题
延时
复制的基本原则
一主一从架构搭建
binlog格式设置
同步数据一致性问题
主从同步的要求
理解主从延迟问题
如何解决一致性问题
方法1: 异步复制
方法2: 半同步复制
方法3: 组复制
数据库备份与恢复
概述
mysqldump实现逻辑备份
备份一个数据库
备份全部数据库
备份部分数据库
备份部分表
备份单表的部分数据
排除某些表的备份
只备份结构
只备份数据
备份中包含存储过程、函数、事件
mysql命令恢复数据
单库备份中恢复单库
全量备份恢复
从全量备份中恢复单库
从单库备份中恢复单表
物理备份：直接复制整个数据库
物理恢复：直接复制到数据库目录
表的导出导入
表的导出
表的导入
数据库迁移
概述
迁移方案
迁移注意点
小结
误删数据恢复
delete: 误删行
truncate/drop: 误删库/表
预防truncate/drop: 误删库/表
rm: 误删MySQL实例