MySQL高级
2022-12-12 17:05:28 1 举报AI智能生成
MySQL高级知识点，思维导图
作者其他创作
大纲/内容
是一种非事务性的引擎，提供高速存储和检索，以及全文搜索能力，适合数据仓库等查询频繁的应用
不支持事务;支持表级锁，并发性差；主机宕机后，MyISAM表易损坏，灾难恢复性不佳；可以配合锁，实现操作系统下的复制备份、迁移
只缓存索引，数据的缓存是利用操作系统缓冲区来实现的;可能引发过多的系统调用且效率不佳；数据紧凑存储，因此可获得更小的索引和更快的全表扫描性能
MyISAM(聚簇集索引)
支持事务的引擎。给MySQL提供了具有提交，回滚和崩溃恢复能力的事务安全（ACID兼容）存储引擎
支持表级锁和行级锁，支持外键关联，支持热备份
当我们用范围条件而不是相等条件检索数据，并请求共享或排他锁时，InnoDB会给符合条件的已有数据的索引项加锁；对于键值在条件范围内但并不存在的记录，叫做“间隙(GAP)”，InnoDB也会对这个“间隙”加锁，这种锁机制不是所谓的间隙锁（Next-Key锁）。InnoDB使用间隙锁的目的，一方面是为了防止幻读，以满足相关隔离级别的要求；另一方面，是为了满足其恢复和复制的需要。
B+tree 数据结构
innoDB(聚簇索引)
存储引擎
叶节点将数据跟索引结构放到一块，因此一个表仅有一个聚簇索引
索引页+数据页组成的B+树
同层级的索引页，互相之间基于指针组成双向链表。
最下层的索引页，有指针引用数据页。即在大的B+树索引数据结构里，叶子节点是数据页本身。
当数据页开始分裂时，会维护上层索引数据结构，在上层索引页里维护索引条目，不同数据页和最小键值。
当数据页越来越多，一个索引页放不下，就会拉出新的索引页，同时加一个上层索引页，上层索引页存放的条目时下层索引页页号和最下主键值。
数据量越大，索引页层级越多，一般索引页可以放很多索引条目，所以通常而言，即使是亿级大表，基本上大表建的索引层级也就三四层。
特点
聚簇索引（一级索引）
由于每个辅助索引都包含主键索引，因此，为了减小辅助索引所占空间，我们通常希望 InnoDB 表中的主键索引尽量定义得小一些，并且希望InnoDB的主键是自增长的，因为如果主键并非自增长，插入时，由于写入时乱序的，会使得插入效率变低。
独立于聚簇索引之外的另一个B+树结构
从小到大排序，下一个数据页索引字段值大于上一个数据页索引字段值
叶子节点仅仅存放主键和索引字段的值，而不保存数据
在索引页，根据索引字段找到数据后，还需要通过主键信息在聚簇索引里从根节点开始查找，一路找到叶子节点的数据页，才能定位到主键对应的完整数据行。
InnoDB采用的方式是在叶子页中保存主键值，通过这个主键值来回表查询到一条完整记录，因此按辅助索引检索实际上进行了二次查询，效率肯定是没有按照主键检索高的
回表
非聚簇索引（二级索引）
物理存储
B+树结构
索引页里保存了下级索引页的页号和最小主键值。通过二分查找可以找到下级索引页。如果最下层的索引页的页号太多，可以再次分裂，再加一层索引页。
针对主键的索引其实就是主键目录，把每个数据页的页号，还有数据页最小的键值放在一起，组成一个索引目录，即索引页。
从小到大排序
innodb主键使用自增bigint效率比uuid高1.方便比较大小2.不会破坏B+TREE结构
建立在主键上的索引被称为主键索引，一张数据表只能有一个主键索引，索引列值不允许有空值，通常在创建表时一起创建
主键索引
建立在UNIQUE字段上的索引被称为唯一索引，一张表可以有多个唯一索引，索引列值允许为空，列值中出现多个空值不会发生重复冲突
唯一索引
建立在普通字段上的索引被称为普通索引
普通索引
对字符类型字段的前几个字符或对二进制类型字段的前几个bytes建立的索引，而不是在整个字段上建索引
前缀索引
字段特性
建立在单个列上的索引被称为单列索引
单列索引
建立在多个列上的索引被称为联合索引，又叫复合索引、组合索引
原理同二级索引，只不过排序的顺序是从靠左边的索引字段开始排序。
查找过程中遇到范围查找的时候，后面的索引字段无法排序。因此设计索引的时候，要把需要做范围查询的索引字段放在最右边。
等值匹配规则
从索引最左侧值开始匹配，不能跳过左边索引字段直接匹配右边索引字段。
最左侧匹配规则
可以用like 'xxx%'的方式匹配
最左前缀匹配规则
可以用select * from table where x1 > xx and x1 < yy这种方式匹配
范围查找规则
等值匹配+范围匹配规则
匹配规则
order by 后面字段顺序和联合索引从最左侧开始字段一致。
group by 后面字段顺序和联合索引从最左侧开始字段一致。
排序/分组走索引提升查询速度
组合索引（联合索引）
字段个数
分类
索引太多，也许查询速度可以提高，但增删改速度比较差。占用磁盘空间也越多，所以索引并不是越多越好。
索引是否越多越好
select 后面跟的字段，即查询的字段，在索引树中，不需要回表去聚簇索引中找其他字段了。
覆盖索引
针对where条件，order by条件，group by条件，join条件on连接字段，去设计索引
尽量使用基数较大的字段（也可以称为散列性高），就是值比较多的字段建立索引，那样才能发挥出B+树快速二分查找的优势来
对那些字段的类型比较小的列来设计索引，这样占用的磁盘空间小，搜索性能好
如果某个较大的字段要建立索引，又不想索引树占太多磁盘空间，可以考虑用这个字段的前20个字符前缀建立索引
避免在索引字段里套函数，进行计算
索引不要设计太多，建议两三个联合索引就应该覆盖掉某个表的全部查询
主键一定要是自增的，别用UUID之类的
设计低基数字段索引时，可以加个复杂辅助字段。
索引设计小技巧
索引列上使用函数（replace/substr/concat/sum/count/avg）表达式
字符串不加引号，出现隐式转换
like条件中前面带%
使用not in或 not exits
索引失效原因
索引
原子性(Atomicity)
一致性(Consistent)
隔离性(Isolation)
持久性(Durable)
ACID属性
两个或多个事务选择同一行，然后基于最初选定的值更新该行时，由于每个事务都不知道其他事务的存在，就会发生丢失更新问题–最后的更新覆盖了由其他事务所做的更新
更新丢失（Lost Update）
一个事务在读取某些数据后的某个时间，再次读取以前读过的数据，却发现其读出的数据已经发生了改变、或某些记录已经被删除了！这种现象就叫做“不可重复读”。 一句话：事务A读取到了事务B已经提交的修改数据，不符合隔离性
不可重读（Non-Repeatable Reads）
事务A读取到了事务B已经修改但尚未提交的数据，还在这个数据基础上做了操作。此时，如果B事务回滚，A读取的数据无效，不符合一致性要求
脏读（Dirty Reads）
一个事务按相同的查询条件重新读取以前检索过的数据，却发现其他事务插入了满足其查询条件的新数据，这种现象就称为“幻读”
幻读（Phantom Reads）
并发事务处理带来的问题
脏读/不可重复读/幻读都可能
读未提交 RU (Read uncommitted)
脏读不可能，可能会发生不可重复读和幻读问题。
读已提交 RC (Read uncommitted)
undo log多版本链条（快照）
ReadViewRC级别下事务的每次重新生成ReadView
可重复读的隔离级别下使用了MVCC机制，select操作不会更新版本号，是快照读（历史版本）insert、update和delete会更新版本号，是当前读（当前版本）
要避免幻读可以用间隙锁在Session _1下面执行update acc ount se t name ='zhuge'where i d> 10and id<= 20;，则其他Session没法插入这个范围内的数据
不可重复读/脏读不可能，可能会出现幻读的问题。
可重复读 RR (Repeatable read)
mysql中事务隔离级别为serializable时会锁表，因此不会出现幻读的情况，这种隔离级别并发性极低，开发中很少会用到
脏读/不可重复读/幻读都不可能
可串行化(Serializable)
SQL标准事务4种隔离级别
show variables like 'transaction_isolation';
select @@transaction_isolation;
查看事务隔离级别
可重复读 RR (Repeatable read)
默认的事务隔离级别
共享锁与共享锁不互斥独占锁、独占锁、共享锁相互互斥通常使用Redis或zookeeper替代显式加锁
事务隔离级别
事务
union会去重，union all不会
横向：表字段相同，数据量太大
join
纵向：一个表存基本信息，另外一个表存详情
分表
客户端程序 : 包括一些mysql工具如：native 或者语言工具如：php 、go 、python
客户端程序
提供多个用户客户端和服务端交互的线程
连接池
接收sql命令，返回查询结果
SQL接口
进行sql语法的解析、语意解析、生成语法树
解析器
mysql核心组件，对sql命令进行优化
优化器
以key -> value方式缓存查询结果 (如果查询sql指令有缓存直接在SQL接口部分返回缓存结果)
缓存
与底层文件惊醒交互，查询数据文件系统、日志文件等
SQL执行组件
2.EXPLAIN+慢SQL分析;
4.具体优化
步骤
explain select * from xxl_job_log l where l.job_id in (select id from xxl_job_info)
语法
表示查询中执行select子句或操作表的顺序
id
SIMPLE：简单的select查询，查询中不包括子查询或者UNION
PRIMARY：查询中若包括任何复杂的子部分，最外层查询则被标记为PRIMARY
SUBQUERY：在select或where列表中包含了子查询
UNION RESULT：从UNION表获取结果的SELECT
物化表
MATERIALIZED
查询的类型
select_type
查询的表
table
在表中找到所需行的方式 ALL、index、range、 ref、eq_ref、const、system、NULL（从左到右，性能从差到好）
全部扫描，效率低
根据双向链表依次把磁盘上的数据页加载到缓存页里去。然后在缓存页内部查找那条数据
ALL
遍历二级索引就能拿到想要的数据，而不需要回表查询
index
只检索给定范围的行，使用一个索引来选择行
explain select * from employee where rec_id < 3其中rec_id为主键
range
通过普通二级非唯一索引（如果是联合索引，须从索引最左侧开始连续多个列都是等值比较才属于ref）+聚簇索引回表快速查询数据的过程
普通索引，查询条件里面包含is null或者is not null
ref
在连接查询时，被驱动表如果基于主键进行等值匹配
eq_ref
通过聚簇索引或者唯一二级索引（即unique key）+聚簇索引回表快速查询数据的过程
性能超高，速度很快，常量级的
const
当MySQL对查询某部分进行优化，并转换为一个常量时，使用这些类型访问。如将主键置于where列表中，MySQL就能将该查询转换为一个常量，system是const类型的特例，当查询的表只有一行的情况下
explain extended select * from (select * from film where id =1) tmp 临时表中只有一条记录
system
NULL： MySQL在优化过程中分解语句，执行时甚至不用访问表或索引，例如从一个索引列里选取最小值可以通过单独索引查找完成explain select min(id) from film id是主键
检索方式
type
指出MySQL能使用哪个索引在表中找到记录，查询涉及到的字段上若存在索引，则该索引将被列出，但不一定被查询使用（该查询可以利用的索引，如果没有任何索引显示 null），可能出现 possible_keys 有列，而 key 显示 NULL 的情况，这种情况是因为表中数据不多，mys ql认为索引对此查询帮助不大，选择了全表查询
possible_keys
显示MySQL实际决定使用的键（索引)
key
表示索引中使用的字节数，可通过该列计算查询中使用的索引的长度（key_len显示的值为索引字段的最大可能长度，并非实际使用长度，即key_len是根据表定义计算而得，不是通过表内检索出的）不损失精确性的情况下，长度越短越好
索引最大长度是768字节，当字符串过长时，mysql会做一个类似左前缀索引的处理，将前半部分的字符提取出来做索引。
字符串\tchar(n)：n字节长度\tvarchar(n)：2字节存储字符串长度，如果是utf-8，则长度3n + 2
数值类型\ttinyint：1字节\tsmallint：2字节\tint：4字节\tbigint：8字节
时间类型 \tdate：3字节timestamp：4字节\tdatetime：8字节如果字段允许为 NULL，需要1字节记录是否为 NULL
计算规则如下
key_len
使用某个字段的索引进行等值匹配搜索的时候，跟索引列进行等值匹配的那个目标值的一些信息
预估通过索引或者别的方式访问这个表的时候，大概会读取到的数据量。
rows
经过搜索条件过来之后剩余数据的百分比
一个半分比的值，rows * filtered/100 可以估算出将要和 explain 中前一个表进行连接的行数（前一个表指 explain 中的id值比当前表id值小的表）
filtered
不用读取表中所有信息，仅通过索引就可以获取所需数据，这发生在对表的全部的请求列都是同一个索引的部分的时候，表示mysql服务器将在存储引擎检索行后再进行过滤
Using where
表示MySQL需要使用临时表来存储结果集，常见于排序和分组查询，常见 group by ; order by;distinct
Using temporary
Using filesort
改值强调了在获取连接条件时没有使用索引，并且需要连接缓冲区来存储中间结果。如果出现了这个值，那应该注意，根据查询的具体情况可能需要添加索引来改进能
Using join buffer
这个值强调了where语句会导致没有符合条件的行（通过收集统计信息不可能存在结果）
Impossible where
这个值意味着仅通过使用索引，优化器可能仅从聚合函数结果中返回一行
Select tables optimized away
Query语句中使用from dual 或不含任何from子句
No tables used
Extra
字段说明
缺点：• EXPLAIN不会告诉你关于触发器、存储过程的信息或用户自定义函数对查询的影响情况• EXPLAIN不考虑各种Cache• EXPLAIN不能显示MySQL在执行查询时所作的优化工作• 部分统计信息是估算的，并非精确值• EXPLAIN只能解释SELECT操作，其他操作要重写为SELECT后查看执行计划
explain
SHOW WARNINGS 在explain执行后执行，查看翻译后的sql
如果有联合索引，必须把联合索引里面每个字段都放SQL里，而且必须是等值匹配。
通过主键+其他二级索引等值匹配，也有可能做一个多索引查询和交集。
如果索引了多列，要遵守最左前缀法则。指的是查询从索引的最左前列开始并且不跳过索引中的列
最佳左前缀法则
使用多个索引的硬性要求
存储引擎不能使用索引中范围条件右边的列EXPLAIN SELECT * FROM employees WHERE name= 'LiLei' AND age = 22 AND position ='manager'; 使用索引EXPLAIN SELECT * FROM employees WHERE name= 'LiLei' AND age > 22 AND position ='manager'; 未使用索引
使用不等于（！=或者<>）的时候无法使用索引会导致全表扫描
like以通配符开头（'$abc...'）mysql索引失效会变成全表扫描操作
字符串不加单引号索引失效（数据类型不要转换）EXPLAIN SELECT * FROM employees WHERE name = '1000';EXPLAIN SELECT * FROM employees WHERE name = 1000;
or 只有两边都有索引才走索引，如果都没有或者只有一个是不走索引的
in操作能避免则避免，若实在避免不了，需要仔细评估in后边的集合元素数量，控制在1000个之内
union all 不去重复，union去重复，union使用了临时表，应尽量避免使用临时表
order by如果根据多个值进行排序，顺序和排序方式 与 多个值建的组合索引一致，否则不走索引
多表关联查询/结果集聚合，根据一个表查一波数据，这个表叫驱动表，再根据这个表去另外一个表查一波数据进行关联，这个表叫被驱动表。应该小表驱动大表
索引优化规则
不同的数据类型的存储和检索方式不同，对应的性能也不同，所以说要合理的选用字段的数据类型。比如人的年龄用无符号的unsigned tinyint即可，没必要用integer
字段的数据类型
数据类型的长度
表的存储引擎
优化数据库表结构的设计
分库分表
数据库参数配置优化
主从复制，读写分离
数据库编码: 采用utf8mb4而不使用utf8
字段名
不同存储引擎对char和varchar的使用原则不同，myisam:建议使用国定长度的数据列代替可变长度。innodb：建议使用varchar，大部分表都是使用innodb，所以varchar的使用频率更高
字符类型
金额类型的字段尽量使用long用单位分表示，尽量不要使用bigdecimal，严禁使用float和double因为计算时会丢失经度如果需要使用小数严禁使用float，double，使用定点数decimal，decimal实际上是以字符串的形式存储的，所以更加精确，java中与之对应的数据类型为BigDecimal如果值为非负数，一定要使用unsigned，无符号不仅能防止负数非法数据的保存，而且还能增大存储的范围
数值类型
日期类型
是否为null
字段类型
where中如果有多个过滤条件，在没有索引的情况下将过滤多的写在前面，过滤少的写在后面
实例
防止回表
禁止使用select *，需要什么字段就去取哪些字段
不要使用count(列名)或 count(常量)来替代 count()，count()是SQL92定义的标准统计行数的语法，跟数据库无关，跟 NULL和非NULL无关。 说明:count(*)会统计值为NULL 的行，而count(列名)不会统计此列为NULL值的行
禁止使用存储过程，存储过程难以调试和扩展，更没有移植性。避免使用存储过程、触发器
优化方式
执行与优化
根据版本号控制
乐观锁
针对同一份数据，多个读操作可以同时进行而不会互相影响
不能进行写操作
读锁(共享锁)
当前写操作没有完成前，它会阻断其他写锁和读锁
写锁(排他锁)
锁定表或者行，让其他数据操作等待
悲观锁
乐观锁和悲观锁
表锁偏向MyISAM存储引擎，开销小，加锁快，无死锁，锁定粒度大，发生锁冲突的概率最高，并发度最低当前session对该表的增删改查都没有问题，其他session对该表的所有操作被阻塞
锁机制 独占锁 意向独占锁 共享锁 意向共享锁独占锁 互斥 不互斥 互斥 互斥意向独占锁 互斥 不互斥 互斥 不互斥共享锁 互斥 互斥 不互斥 不互斥意向共享锁 互斥 不互斥 不互斥 不互斥
互斥性
独占锁lock tables tableName write
意向独占锁（事务自动）
共享锁lock tables tableName read
意向共享锁（事务自动）
类型
通常不会手动加表锁
表锁
行锁偏向InnoDB存储引擎，开销大，加锁慢，会出现死锁，锁定粒度最小，发生锁冲突的概率最低，并发度也最高。InnoDB与MYISAM的最大不同有两点：一是支持事务（TRANSACTION）；二是采用了行级锁
定义：读取记录的可见版本（可能是历史版本），不加锁
普通 select
表现
快照读snapshot read
定义：读取记录最新版本，会加锁保证不并发修改
特殊查询 select .. where ？ for update 加独占锁 X
select .. where ？ lock in share mode 加共享锁 S
insert，update，delete等 DML操作 加x锁
当前读current read
更新一行数据必须把他所在的数据页从磁盘文件读取到缓存中才能更新，所以此时这行数据和关联的锁数据结构，都是在内存里面的。
形态
针对当前读，innoDB交互是一条一条的进行，加锁也是一条一条
发送一个update语句
使用当前读取出第一条并加锁
mysql 收到会再发一个update请求，更新这条记录
完成后再读下一条重复上述过程
过程
2PL就是将加锁/解锁分为两个完全不相交的阶段。加锁阶段：只加锁，不放锁。解锁阶段：只放锁，不加锁
两阶段锁实现
通过索引+mvcc 实现
锁类型 独占锁 共享锁独占锁 互斥 互斥共享锁 互斥 不互斥
行锁
表锁和行锁
执行DDL时，会阻塞增删改操作，执行增删改操作时，会阻塞DDL操作。
元数据锁（Metadata Locks）
当前正在等待锁定的数量
Innodb_row_ lock_current_wait
从系统启动到现在锁定总时间长度
Innodb_row_ lock_time
每次等待所花平均时间
Innodb_row_ lock_time_avg
从系统启动到现在等待最长的一次所花时间
Innodb_row_ lock_time_max
系统启动后到现在总共等待的次数
Innodb_row_ lock_waits
show status like'innodb_row_lock%';
行锁分析
Session _1执行：select *from account where i d= 1 for update;Session _2执行：select *from account where i d= 2 for update;Session _1执行：select *from account where i d= 2 for update;Session _2执行：select *from account where i d= 1 for update;查看近期死锁日志信息：show engine inno db statu s\\G;
死锁
锁
一种用来解决读-写冲突的无锁并发控制，也就是为事务分配单向增长的时间戳，为每个修改保存一个版本，版本与事务时间戳关联，读操作只读该事务开始前的数据库的快照
在并发读写数据库时，可以做到在读操作时不用阻塞写操作，写操作也不用阻塞读操作，提高了数据库并发读写的性能
同时还可以解决脏读，幻读，不可重复读等事务隔离问题，但不能解决更新丢失问题
为数据库解决
MVCC + 悲观锁:MVCC解决读写冲突，悲观锁解决写写冲突
MVCC + 乐观锁:MVCC解决读写冲突，乐观锁解决写写冲突
两个组合
原理主要是依赖记录中的 3个隐式字段，undo日志 ，Read View 来实现的
DB_TRX_ID 6字节 ;事务id，随事务增加
DB_ROLL_PTR 7字节 回滚指针
DB_ROW_ID 隐藏的id，随记录自然增长
隐含字段
update undo log:事务在进行update或delete时产生的undo log; 不仅在事务回滚时需要，在快照读时也需要；所以不能随便删除，只有在快照读或事务回滚不涉及该日志时，对应的日志才会被purge线程统一清除
undo log
1、当前session 事务版本号>=DB_TRX_ID
2、delete_id is null or 当前事务号<DB_TRX_ID
select
新插入的行，DB_TRX_ID=当前事务号
insert
更新行的时候，InnoDB会把原来行复制一份，DB_TRX_ID=当前事务号
update
设置删除版本号为当前事务id (DB_TRX_ID=当前事务号??) delete_id = 当前事务号
相当于标记为删除，而不是物理的删除。真是的删除是在InnoDB的purge线程去做的。
delete
commit
根据当前回滚指针从undo log中找出事务修改前的版本，并恢复
rollback
从数据的最早版本开始判断（undo log）
数据版本trx_id = creator_trx_id， 当前事务修改，可以访问。
数据版本trx_id < min_trx_id，这个版本在生成readview已经提交，可以访问。
数据版本trx_id > max_trx_id，这个版本是生成read_view之后才开启的事务建立的，不能访问。
数据版本trx_id在min_trx_id和max_trx_id之间，看是否在m_ids中，不过在，不可以访问，不在则可以访问，
如果当前版本不可见，如果不在，可以。
判断规则
机制
ReadView机制
mvcc
主从复制是指数据可以从一个MySQL数据库服务器主节点复制到一个或多个从节点。MySQL 默认采用异步复制方式，这样从节点不用一直访问主服务器来更新自己的数据，数据的更新可以在远程连接上进行，从节点可以复制主数据库中的所有数据库或者特定的数据库，或者特定的表
MySql主库在事务提交时会把数据变更作为事件记录在二进制日志Binlog中
主库推送二进制日志文件Binlog中的事件到从库的中继日志Relay Log中，之后从库根据中继日志重做数据变更操作，通过逻辑复制来达到主库和从库的数据一致性
MySql通过三个线程来完成主从库间的数据复制，其中Binlog Dump线程跑在主库上，I/O线程和SQL线程跑着从库上
当在从库上启动复制时，首先创建I/O线程连接主库，主库随后创建Binlog Dump线程读取数据库事件并发送给I/O线程，I/O线程获取到事件数据后更新到从库的中继日志Relay Log中去，之后从库上的SQL线程读取中继日志Relay Log中更新的数据库事件并应用
原理
主节点更新数据时，会在事务前产生GTID，一起记录到binlog日志中
从节点的I/O线程将变更的bin log，写入到本地的relay log中
SQL线程从relay log中获取GTID，然后对比本地binlog是否有记录（所以MySQL从节点必须要开启binary log）
如果有记录，说明该GTID的事务已经执行，从节点会忽略
如果没有记录，从节点就会从relay log中执行该GTID的事务，并记录到bin log
在解析过程中会判断是否有主键，如果没有就用二级索引，如果有就用全部扫描
基于GTID复制实现的工作原理
读写分离
数据实时备份，当系统中某个节点发生故障时，可以方便的故障切换
高可用HA
架构扩展
用途
一主一从
一主多从
多主一从
互做主从复制，每个master既是master，又是另外一台服务器的slave。这样任何一方所做的变更，都会通过复制应用到另外一方的数据库中
双主复制
部分slave的数据同步不连接主节点，而是连接从节点
主节点有太多的从节点，就会损耗一部分性能用于replication
级联复制
主从形式
主节点不会主动push bin log到从节点，这样有可能导致failover的情况下，也许从节点没有即时地将最新的bin log同步到本地
异步模式(MYSQL的默认设置)
主节点只需要接收到其中一台从节点的返回信息，就会commit;否则需要等待直到超时时间然后切换成异步模式再提交；这样做的目的可以使主从数据库的数据延迟缩小，可以提高数据安全性，确保了事务提交后，binlog至少传输到了一个从节点上，不能保证从节点将此事务更新到db中。性能上会有一定的降低，响应时间会变长
半同步模式
主节点和从节点全部执行了commit并确认才会向客户端返回成功
全同步模式
主从复制模式
基于SQL语句的复制（statement-based replication，SBR
基于行的复制（row-based replication，RBR)
三种方式
基于二进制日志点的复制
基于GTID的复制（MySQL>=5.7推荐使用）
复制类型
主从同步
MySQL高级
0 条评论
回复 删除
下一页
