百度百科上的解释:MySQL是一种开放源代码的关系型数据库管理系统(RDBMS),使用最常用的数据库管理语言–结构化查询语言(SQL)进行数据库管理。MySQL是开放源代码的,因此任何人都可以在General Public License的许可下下载并根据个性化的需要对其进行修改。
InnoDB是MySQL的默认存储引擎,支持事务、行锁和外键等操作。
MyISAM是MySQL5.1版本前的默认存储引擎,MyISAM的并发性比较差,不支持事务和外键等操作,默认的锁的粒度为表级锁。
InnoDB | MyISAM | |
---|---|---|
外键 | 支持 | 不支持 |
事务 | 支持 | 不支持 |
锁 | 支持表锁和行锁 | 支持表锁 |
可恢复性 | 根据事务日志进行恢复 | 无事务日志 |
表结构 | 数据和索引是集中存储的,.ibd和.frm 数据和索引是分开存储的 , | 数据.MYD,索引.MYI |
查询性能 | 一般情况相比于MyISAM较差 | 一般情况相比于InnoDB较差 |
索引 | 聚簇索引 | 非聚簇索引 |
TINYINT、SMALLINT、MEDIUMINT、INT、BIGINT分别占用8、16、24、32、64位存储空间。值得注意的是,INT(10)中的10只是表示显示字符的个数,并无实际意义。一般和UNSIGNED ZEROFILL配合使用才有实际意义,例如,数据类型INT(3),属性为UNSIGNED ZEROFILL,如果插入的数据为3的话,实际存储的数据为003。
FLOAT、DOUBLE及DECIMAL为浮点数类型,DECIMAL是利用字符串进行处理的,能存储精确的小数。相比于FLOAT和DOUBLE,DECIMAL的效率更低些。FLOAT、DOUBLE及DECIMAL都可以指定列宽,例如FLOAT(5,2)表示一共5位,两位存储小数部分,三位存储整数部分。
字符串常用的主要有CHAR和VARCHAR,VARCHAR主要用于存储可变长字符串,相比于定长的CHAR更节省空间。CHAR是定长的,根据定义的字符串长度分配空间。
应用场景:对于经常变更的数据使用CHAR更好,CHAR不容易产生碎片。对于非常短的列也是使用CHAR更好些,CHAR相比于VARCHAR在效率上更高些。一般避免使用TEXT/BLOB等类型,因为查询时会使用临时表,造成严重的性能开销。
比较常用的有year、time、date、datetime、timestamp等,datetime保存从1000年到9999年的时间,精度位秒,使用8字节的存储空间,与时区无关。timestamp和UNIX的时间戳相同,保存从1970年1月1日午夜到2038年的时间,精度到秒,使用四个字节的存储空间,并且与时区相关。
应用场景:尽量使用timestamp,相比于datetime它有着更高的空间效率。
索引是对数据库表的一列或者多列的值进行排序一种结构,使用索引可以快速访问数据表中的特定信息。
索引的数据结构主要有B+树和哈希表,对应的索引分别为B+树索引和哈希索引。InnoDB引擎的索引类型有B+树索引和哈希索引,默认的索引类型为B+树索引。
熟悉数据结构的同学都知道,B+树、平衡二叉树、红黑树都是经典的数据结构。在B+树中,所有的记录节点都是按照键值大小的顺序放在叶子节点上,如下图。
从上图可以看出 ,因为B+树具有有序性,并且所有的数据都存放在叶子节点,所以查找的效率非常高,并且支持排序和范围查找。
B+树的索引又可以分为主索引和辅助索引。其中主索引为聚簇索引,辅助索引为非聚簇索引。聚簇索引是以主键作为B+ 树索引的键值所构成的B+树索引,聚簇索引的叶子节点存储着完整的数据记录;非聚簇索引是以非主键的列作为B+树索引的键值所构成的B+树索引,非聚簇索引的叶子节点存储着主键值。所以使用非聚簇索引进行查询时,会先找到主键值,然后到根据聚簇索引找到主键对应的数据域。上图中叶子节点存储的是数据记录,为聚簇索引的结构图,非聚簇索引的结构图如下:
上图中的字母为数据的非主键的列值,假设要查询该列值为B的信息,则需先找到主键7,在到聚簇索引中查询主键7所对应的数据域。
哈希索引是基于哈希表实现的,对于每一行数据,存储引擎会对索引列通过哈希算法进行哈希计算得到哈希码,并且哈希算法要尽量保证不同的列值计算出的哈希码值是不同的,将哈希码的值作为哈希表的key值,将指向数据行的指针作为哈希表的value值。这样查找一个数据的时间复杂度就是o(1),一般多用于精确查找。
因为两者数据结构上的差异导致它们的使用场景也不同,哈希索引一般多用于精确的等值查找,B+索引则多用于除了精确的等值查找外的其他查找。在大多数情况下,会选择使用B+树索引。
MySQL主要的索引类型主要有FULLTEXT,HASH,BTREE,RTREE。
FULLTEXT即全文索引,MyISAM存储引擎和InnoDB存储引擎在MySQL5.6.4以上版本支持全文索引,一般用于查找文本中的关键字,而不是直接比较是否相等,多在CHAR,VARCHAR,TAXT等数据类型上创建全文索引。全文索引主要是用来解决WHERE name LIKE "%zhang%"等针对文本的模糊查询效率低的问题。
HASH即哈希索引,哈希索引多用于等值查询,时间复杂夫为o(1),效率非常高,但不支持排序、范围查询及模糊查询等。
BTREE即B+树索引,INnoDB存储引擎默认的索引,支持排序、分组、范围查询、模糊查询等,并且性能稳定。
RTREE即空间数据索引,多用于地理数据的存储,相比于其他索引,空间数据索引的优势在于范围查找
B树和B+树最主要的区别主要有两点:
B树中的内部节点和叶子节点均存放键和值,而B+树的内部节点只有键没有值,叶子节点存放所有的键和值。
B+树的叶子节点是通过相连在一起的,方便顺序检索。
聚簇索引和非聚簇索引最主要的区别是数据和索引是否分开存储。
在MyISAM存储引擎中,默认的索引也是B+树索引,但主索引和辅助索引都是非聚簇索引,也就是说索引结构的叶子节点存储的都是一个指向数据行的地址。并且使用辅助索引检索无需访问主键的索引。
上面是说了非聚簇索引的叶子节点存储的是主键,也就是说要先通过非聚簇索引找到主键,再通过聚簇索引找到主键所对应的数据,后面这个再通过聚簇索引找到主键对应的数据的过程就是回表查询,那么非聚簇索引就一定会进行回表查询吗?
答案是不一定的,这里涉及到一个索引覆盖的问题,如果查询的数据再辅助索引上完全能获取到便不需要回表查询。例如有一张表存储着个人信息包括id、name、age等字段。假设聚簇索引是以ID为键值构建的索引,非聚簇索引是以name为键值构建的索引,select id,name from user where name = ‘zhangsan’;这个查询便不需要进行回表查询因为,通过非聚簇索引已经能全部检索出数据,这就是索引覆盖的情况。如果查询语句是这样,select id,name,age from user where name = ‘zhangsan’;则需要进行回表查询,因为通过非聚簇索引不能检索出age的值。那应该如何解决那呢?只需要将索引覆盖即可,建立age和name的联合索引再使用select id,name,age from user where name = ‘zhangsan’;进行查询即可。
所以通过索引覆盖能解决非聚簇索引回表查询的问题。
对索引的优化其实最关键的就是要符合索引的设计原则和应用场景,将不符合要求的索引优化成符合索引设计原则和应用场景的索引。
除了索引的设计原则和应用场景那几点外,还可以从以下两方面考虑。
创建索引:
CREATE INDEX index_name ON table_name (column_list);
CREATE TABLE user( id INT PRIMARY KEY, information text, FULLTEXT KEY (information) );
ALTER TABLE table_name ADD INDEX index_name (column_list);
删除索引:
alter table 表名 drop primary key
alter table 表名 drop key 索引名
不一定,前面在索引的使用场景和索引的设计原则中已经提到了如何合理地使用索引,因为创建和维护索引需要花费空间和时间上的代价,如果不合理地使用索引反而会使查询性能下降。
前缀索引是指对文本或者字符串的前几个字符建立索引,这样索引的长度更短,查询速度更快。
使用场景:前缀的区分度比较高的情况下。
建立前缀索引的方式
ALTER TABLE table_name ADD KEY(column_name(prefix_length));
这里面有个prefix_length参数很难确定,这个参数就是前缀长度的意思。通常可以使用以下方法进行确定,先计算全列的区分度
SELECT COUNT(DISTINCT column_name) / COUNT(*) FROM table_name;
然后在计算前缀长度为多少时和全列的区分度最相似。
SELECT COUNT(DISTINCT LEFT(column_name, prefix_length)) / COUNT(*) FROM table_name;
不断地调整prefix_length的值,直到和全列计算出区分度相近。
最左匹配原则:从最左边为起点开始连续匹配,遇到范围查询(<、>、between、like)会停止匹配。
例如建立索引(a,b,c),大家可以猜测以下几种情况是否用到了索引。
第一种
select * from table_name where a = 1 and b = 2 and c = 3 select * from table_name where b = 2 and a = 1 and c = 3
上面两次查询过程中所有值都用到了索引,where后面字段调换不会影响查询结果,因为MySQL中的优化器会自动优化查询顺序。
第二种
select * from table_name where a = 1 select * from table_name where a = 1 and b = 2 select * from table_name where a = 1 and b = 2 and c = 3
答案是三个查询语句都用到了索引,因为三个语句都是从最左开始匹配的。
第三种
select * from table_name where b = 1 select * from table_name where b = 1 and c = 2
答案是这两个查询语句都没有用到索引,因为不是从最左边开始匹配的
第四种
select * from table_name where a = 1 and c = 2
这个查询语句只有a列用到了索引,c列没有用到索引,因为中间跳过了b列,不是从最左开始连续匹配的。
第五种
select * from table_name where a = 1 and b < 3 and c < 1
这个查询中只有a列和b列使用到了索引,而c列没有使用索引,因为根据最左匹配查询原则,遇到范围查询会停止。
第六种
select * from table_name where a like 'ab%'; select * from table_name where a like '%ab' select * from table_name where a like '%ab%'
对于列为字符串的情况,只有前缀匹配可以使用索引,中缀匹配和后缀匹配只能进行全表扫描。
在上面介绍了几种不符合最左匹配原则的情况会导致索引失效,除此之外,以下这几种情况也会导致索引失效。
数据库事务( transaction)是访问并可能操作各种数据项的一个数据库操作序列,这些操作要么全部执行,要么全部不执行,是一个不可分割的工作单位。事务由事务开始与事务结束之间执行的全部数据库操作组成。
当多个事务并发执行时,可能会出现以下问题:
隔离级别 | 脏读 | 不可重复读 | 幻读 |
---|---|---|---|
未提交读 | 允许 | 允许 | 允许 |
提交读 | 不允许 | 允许 | 允许 |
可重复读 | 不允许 | 不允许 | 允许 |
串行化 | 不允许 | 不允许 | 不允许 |
事务的隔离机制主要是依靠锁机制和MVCC(多版本并发控制)实现的,提交读和可重复读可以通过MVCC实现,串行化可以通过锁机制实现。
MVCC(multiple version concurrent control)是一种控制并发的方法,主要用来提高数据库的并发性能。
在了解MVCC时应该先了解当前读和快照读。
MVCC的实现原理:
版本号
系统版本号:是一个自增的ID,每开启一个事务,系统版本号都会递增。
事务版本号:事务版本号就是事务开始时的系统版本号,可以通过事务版本号的大小判断事务的时间顺序。
行记录隐藏的列
DB_ROW_ID:所需空间6byte,隐含的自增ID,用来生成聚簇索引,如果数据表没有指定聚簇索引,InnoDB会利用这个隐藏ID创建聚簇索引。
DB_TRX_ID:所需空间6byte,最近修改的事务ID,记录创建这条记录的事务ID。
DB_ROLL_PTR:所需空间7byte,回滚指针,指向这条记录的上一个版本。
它们大致长这样,省略了具体字段的值。
undo日志
MVCC使用到的快照会存储在Undo日志中,该日志通过回滚指针将一个一个数据行的所有快照连接起来。它们大致长这样
举一个例子说明下,比如最开始的某条记录长这样
现在来了一个事务对他的年龄字段进行了修改,就变成了这样
现在又来了一个事务对它的性别进行了修改,它又变成了这样
从上面的分析可以看出,事务对同一记录的修改,每条记录会在Undo日志中连接成一个线性表,在表头的就是最新的旧记录。
在重复读的隔离级别下,InnoDB的工作流程:
SELECT
作为查询的结果满足两个条件:
INSERT
将当前系统版本号作为数据行快照的创建版本号
DELETE
将当前系统版本号作为数据行快照的删除版本号
UPDATE
保存当前系统版本号为更新前的数据行快照创建行版本号,并保存当前系统版本号为更新后的数据行快照的删除版本号,其实就是,先删除再插入即为更新。
总结一下,MVCC的作用是在避免加锁的情况下最大限度的解决读写并发冲突的问题,它可以实现提交读和可重复读两个隔离级。
当数据库有并发事务的时候,保证数据访问顺序的机制称为锁机制。
隔离级别 | 实现方式 |
---|---|
未提交读 | 总是读取最新的数据,无需加锁 |
提交读 | 读取数据时加共享锁,读取数据后释放共享锁 |
可重复读 | 读取数据时加共享锁,事务结束后释放共享锁 |
串行化 | 锁定整个范围的键,一直持有锁直到事务结束 |
按照锁的粒度可以将MySQL锁分为三种:
MySQL锁类别 | 资源开销 | 加锁速度 | 是否会出现死锁 | 锁的粒度 | 并发度 |
---|---|---|---|---|---|
表级锁 | 小 | 快 | 不会 | 大 | 低 |
行级锁 | 大 | 慢 | 会 | 小 | 高 |
页面锁 | 一般 | 一般 | 不会 | 一般 | 一般 |
MyISAM默认采用表级锁,InnoDB默认采用行级锁。
从锁的类别上区别可以分为共享锁和排他锁
行锁模式
在存在行锁和表锁的情况下,一个事务想对某个表加X锁时,需要先检查是否有其他事务对这个表加了锁或对这个表的某一行加了锁,对表的每一行都进行检测一次这是非常低效率的,为了解决这种问题,实现多粒度锁机制,InnoDB还有两种内部使用的意向锁,两种意向锁都是表锁。
InnoDB行锁主要分三种情况:
InnoDB行锁的特性:如果不通过索引条件检索数据,那么InnoDB将对表中所有记录加锁,实际产生的效果和表锁是一样的。
MVCC不能解决幻读问题,在可重复读隔离级别下,使用MVCC+Next-Key Locks 可以解决幻读问题。
乐观锁:系统假设数据的更新在大多时候是不会产生冲突的,所以数据库只在更新操作提交的时候对数据检测冲突,如果存在冲突,则数据更新失败。
乐观锁实现方式:一般通过版本号和CAS算法实现
悲观锁:假定会发生并发冲突,屏蔽一切可能违反数据库完整性的操作。通俗讲就是每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁。
悲观锁的实现方式:通过数据库的锁机制实现,对查询语句添加for update
死锁是指两个或者两个以上进程在执行优化过程中,由于竞争资源或者由于彼此通信而造成的一种阻塞的现象。在MySQL中,MyISAM是一次性获得所需的全部锁,要么全部满足,要么等待,所以不会出现死锁。在InnoDB存储引擎中,除了单个SQL组成的事物外,锁都是逐步获得的,所以存在死锁问题。
如何避免MySQL发生死锁或者锁冲突:
子查询:把一个查询的结果在另一个查询中使用
SELECT * FROM user WHERE age = (SELECT max(age) from user) //查询年纪最大的人
SELECT num1 FROM table1 WHERE num1 > ANY (SELECT num2 FROM table2)
SELECT * FROM user WHERE (age,sex) = (SELECT age,sex FROM user WHERE name="zhangsan")
SELECT * FROM student WHERE (name,age,sex) IN (SELECT name,age,sex FROM class1) //在学生表中找到班级在1班的学生
MySQl的连接查询主要可以分为外连接,内连接,交叉连接
外连接包括左连接和右连接
内连接查询:查询的结果为两个表匹配到的数据
交叉连接,使用笛卡尔积的一种连接。
笛卡尔积:两个集合X和Y的笛卡尔积表示为X × Y,第一个对象是X的成员而第二个对象是Y的所有可能有序对的其中一个成员 。例如:A={a,b},B={0,1,2},A × B = {(a,0),(a,1),(a,2),(b,0),(b,1),(b,2)}
举例如下:有两张表分为L表和R表。
L表
A | B |
---|---|
a1 | b1 |
a2 | b2 |
a3 | b3 |
R 表
B | C |
---|---|
b1 | c1 |
b2 | c2 |
b4 | c3 |
*
,R.*
from L,RA | B | B | C |
---|---|---|---|
a1 | b1 | b1 | c1 |
a1 | b1 | b2 | c2 |
a1 | b1 | b4 | c3 |
a2 | b2 | b1 | c1 |
a2 | b2 | b2 | c2 |
a2 | b2 | b4 | c3 |
a3 | b3 | b1 | c1 |
a3 | b3 | b2 | c2 |
a3 | b3 | b4 | c3 |
in和exists一般用于子查询。
int(10)中的10表示的是显示数据的长度,而char(10)和varchar(10)表示的是存储数据的大小。
drop | delete | truncate | |
---|---|---|---|
速度 | 快 | 逐行删除,慢 | 较快 |
类型 | DDL | DML | DDL |
回滚 | 不可回滚 | 可回滚 | 不可回滚 |
删除内容 | 删除整个表,数据行、索引都会被删除 | 表结构还在,删除表的一部分或全部数据 | 表结构还在,删除表的全部数据 |
一般来讲,删除整个表,使用drop,删除表的部分数据使用delete,保留表结构删除表的全部数据使用truncate。
union和union all的作用都是将两个结果集合并到一起。
MySQL在执行SQL语句的时候会临时创建一些存储中间结果集的表,这种表被称为临时表,临时表只对当前连接可见,在连接关闭后,临时表会被删除并释放空间。
临时表主要分为内存临时表和磁盘临时表两种。内存临时表使用的是MEMORY存储引擎,磁盘临时表使用的是MyISAM存储引擎。
一般在以下几种情况中会使用到临时表:
慢查询一般用于记录执行时间超过某个临界值的SQL语句的日志。
相关参数:
slow_query_log:是否开启慢日志查询,1表示开启,0表示关闭。
slow_query_log_file:MySQL数据库慢查询日志存储路径。
long_query_time:慢查询阈值,当SQL语句查询时间大于阈值,会被记录在日志上。
log_queries_not_using_indexes:未使用索引的查询会被记录到慢查询日志中。
log_output:日志存储方式。“FILE”表示将日志存入文件。“TABLE”表示将日志存入数据库。
如何对慢查询进行优化?
分析语句的执行计划,查看SQL语句的索引是否命中
优化数据库的结构,将字段很多的表分解成多个表,或者考虑建立中间表。
优化LIMIT分页。
主键是唯一区分表中每一行的唯一标识,如果没有主键,更新或者删除表中特定的行会很困难,因为不能唯一准确地标识某一行。
使用自增ID的好处:
使用自增ID的缺点:
UUID:通用唯一标识码,UUID是基于当前时间、计数器和硬件标识等数据计算生成的。
使用UUID的优点:
使用UUID的缺点:
最后说下结论,一般情况MySQL推荐使用自增ID。因为在MySQL的InnoDB存储引擎中,主键索引是一种聚簇索引,主键索引的B+树的叶子节点按照顺序存储了主键值及数据,如果主键索引是自增ID,只需要按顺序往后排列即可,如果是UUID,ID是随机生成的,在数据插入时会造成大量的数据移动,产生大量的内存碎片,造成插入性能的下降。
首先说一点,NULL和空值是不一样的,空值是不占用空间的,而NULL是占用空间的,所以字段设为NOT NULL后仍然可以插入空值。
字段设置成not null主要有以下几点原因:
NULL值会影响一些函数的统计,如count,遇到NULL值,这条记录不会统计在内。
B树不存储NULL,所以索引用不到NULL,会造成第一点中说的统计不到的问题。
NOT IN子查询在有NULL值的情况下返回的结果都是空值。
例如user表如下
id | username |
---|---|
0 | zhangsan |
1 | lisi |
2 | null |
select * from user
where username NOT IN (select username from user
where id != 0),这条查询语句应该查到zhangsan这条数据,但是结果显示为null。
从减少数据访问方面考虑:
从返回更少的数据方面考虑:
合理使用排序
客户端多进程并行访问
在LIMIT偏移量较大的时候,查询效率会变低,可以记录每次取出的最大ID,下次查询时可以利用ID进行查询
建立复合索引、
如果不需要对结果集进行去重或者排序建议使用UNION ALL,会好一些。
SELECT DISTINCT select_list FROM left_table LEFT JOIN right_table ON join_condition WHERE where_condition GROUP BY group_by_list HAVING having_condition ORDER BY order_by_condition
执行顺序如下:
FROM:对SQL语句执行查询时,首先对关键字两边的表以笛卡尔积的形式执行连接,并产生一个虚表V1。虚表就是视图,数据会来自多张表的执行结果。
ON:对FROM连接的结果进行ON过滤,并创建虚表V2
JOIN:将ON过滤后的左表添加进来,并创建新的虚拟表V3
WHERE:对虚拟表V3进行WHERE筛选,创建虚拟表V4
GROUP BY:对V4中的记录进行分组操作,创建虚拟表V5
HAVING:对V5进行过滤,创建虚拟表V6
SELECT:将V6中的结果按照SELECT进行筛选,创建虚拟表V7
DISTINCT:对V7表中的结果进行去重操作,创建虚拟表V8,如果使用了GROUP BY子句则无需使用DISTINCT,因为分组的时候是将列中唯一的值分成一组,并且每组只返回一行记录,所以所有的记录都h是不同的。
ORDER BY:对V8表中的结果进行排序。
垂直分表:将一个表按照字段分成多个表,每个表存储其中一部分字段。一般会将常用的字段放到一个表中,将不常用的字段放到另一个表中。
垂直分表的优势:
避免IO竞争减少锁表的概率。因为大的字段效率更低,第一数据量大,需要的读取时间长。第二,大字段占用的空间更大,单页内存储的行数变少,会使得IO操作增多。
可以更好地提升热门数据的查询效率。
垂直分库:按照业务对表进行分类,部署到不同的数据库上面,不同的数据库可以放到不同的服务器上面。
垂直分库的优势:
垂直拆分(分库、分表)的缺点:
水平分表的优势:
水平分库的优势:
解决了单库大数据量的瓶颈问题
IO冲突减少,锁的竞争减少,某个数据库出现问题不影响其他数据库(可用性),提高了系统的稳定性和可用性
水平拆分(分表、分库)的缺点:
分片事务一致性难以解决
跨节点JOIN性能差,逻辑会变得复杂
数据扩展难度大,不易维护
在系统设计时应根据业务耦合来确定垂直分库和垂直分表的方案,在数据访问压力不是特别大时应考虑缓存、读写分离等方法,若数据量很大,或持续增长可考虑水平分库分表,水平拆分所涉及的逻辑比较复杂,常见的方案有客户端架构和恶代理架构。
分库分表后不能每个表的ID都是从1开始,所以需要一个全局ID,设置全局ID主要有以下几种方法:
UUID:优点:本地生成ID,不需要远程调用;全局唯一不重复。缺点:占用空间大,不适合作为索引。
数据库自增ID:在分库分表表后使用数据库自增ID,需要一个专门用于生成主键的库,每次服务接收到请求,先向这个库中插入一条没有意义的数据,获取一个数据库自增的ID,利用这个ID去分库分表中写数据。优点:简单易实现。缺点:在高并发下存在瓶颈。系统结构如下图(图片来源于网络)
Redis生成ID:优点:不依赖数据库,性能比较好。缺点:引入新的组件会使得系统复杂度增加
Twitter的snowflake算法:是一个64位的long型的ID,其中有1bit是不用的,41bit作为毫秒数,10bit作为工作机器ID,12bit作为序列号。
1bit:第一个bit默认为0,因为二进制中第一个bit为1的话为负数,但是ID不能为负数.
41bit:表示的是时间戳,单位是毫秒。
10bit:记录工作机器ID,其中5个bit表示机房ID,5个bit表示机器ID。
12bit:用来记录同一毫秒内产生的不同ID。
美团的Leaf分布式ID生成系统,美团点评分布式ID生成系统
MySQL复制:为保证主服务器和从服务器的数据一致性,在向主服务器插入数据后,从服务器会自动将主服务器中修改的数据同步过来。
主从复制的原理:
主从复制主要有三个线程:binlog线程,I/O线程,SQL线程。
binlog线程:负责将主服务器上的数据更改写入到二进制日志(Binary log)中。
I/O线程:负责从主服务器上读取二进制日志(Binary log),并写入从服务器的中继日志(Relay log)中。
SQL线程:负责读取中继日志,解析出主服务器中已经执行的数据更改并在从服务器中重放
复制过程如下(图片来源于网络):
读写分离主要依赖于主从复制,主从复制为读写分离服务。
读写分离的优势:
转自牛客网
作者:路人zhang
链接:https://www.nowcoder.com/discuss/637486?source_id=profile_create_nctrack&channel=-1
来源:牛客网