目录
- 数据库MySQL学习笔记高级篇
- 写在前面
- 1. mysql的架构介绍
- mysql简介
- mysqlLinux版的安装
- mysql配置文件
- mysql逻辑架构介绍
- mysql存储引擎
- 2. 索引优化分析
- 性能下降SQL慢
- 常见通用的Join查询
- 索引简介
- 性能分析
- 索引优化
- 3. 查询截取分析
- 查询优化
- 慢查询日志
- 批量数据脚本
- Show Profile
- 全局查询日志
- 4. MySQL锁机制
- 概述
- 三锁
- 5. 主从复制
- 复制的基本原理
- 复制的基本原则
- 复制的最大问题
- 一主一从常见配置
数据库MySQL学习笔记高级篇
写在前面
学习链接:数据库 MySQL 视频教程全集
1. mysql的架构介绍
mysql简介
概述
高级Mysql
- 完整的mysql优化需要很深的功底,大公司甚至有专门的DBA写上述
- mysql内核
- sql优化工程师
- mysql服务器的优化
- 各种参数常量设定
- 查询语句优化
- 主从复制
- 软硬件升级
- 容灾备份
- sql编程
mysqlLinux版的安装
- mysql5.5
下载地址:https://dev.mysql.com/downloads/mysql/5.5.html#downloads
检查当前系统是否安装过mysql:
- 查询命令:rpm -qa|grep -i mysql
- 删除命令:rpm -e RPM软件包名称
- 删除自带的mysql:yum -y remove mysql-libs-5.1.73-7.el6.x86_64
安装mysql服务端(注意提示):
- rpm -ivh MySQL-server-5.5.48-1.linux2.6.i386.rpm
- 如果报错libc.so.6:https://blog.csdn.net/xiyuliuyang/article/details/90750049
- 如果警告key ID 5072e1f5: NOKEY:https://blog.csdn.net/Aaron960214/article/details/78451321
- rpm -ivh MySQL-server-5.5.48-1.linux2.6.i386.rpm
安装mysql客户端
- rpm -ivh MySQL-client-5.5.48-1.linux2.6.i386.rpm
查看MySQL安装时创建的mysql用户和mysql组
- cat /etc/passwd|grep mysql
- cat /etc/group|grep mysql
- mysqladmin --version
- cat /etc/passwd|grep mysql
mysql服务的启+停
service mysql start
service mysql start
如果报错ERROR! The server quit without updating PID file (/var/lib/mysql/localhost.localdomain.pid).
解决办法:https://www.cnblogs.com/bingco/p/8068243.html
mysql_install_db --datadir=/var/lib/mysql chown mysql:mysql /var/lib/mysql -R
查看mysql的进程:ps -ef|grep mysql
mysql服务启动后,开始连接
- 首次连接成功:mysql(不需要输入密码)
- 给root用户设置密码:/usr/bin/mysqladmin -u root password 123456
- 首次连接成功:mysql(不需要输入密码)
自启动mysql服务
- 设置开机自启动mysql:chkconfig mysql on
- 查看mysql的等级:chkconfig --list | grep mysql
- 查看不同等级代表的含义:cat /etc/inittab
- 查看开机自动服务有哪些:ntsysv
- 设置开机自启动mysql:chkconfig mysql on
修改配置文件位置
- 版本5.5:cp /usr/share/mysql/my-huge.cnf /etc/my.cnf
- 版本5.6:cp /usr/share/mysql/my-default.cnf /etc/my.cnf
- 版本5.5:cp /usr/share/mysql/my-huge.cnf /etc/my.cnf
修改字符集和数据存储路径
MySQL的安装位置
- /var/lib/mysql:mysql数据库文件的存放路径
- /usr/share/mysql:配置文件目录
- /usr/bin:相关命令目录
- /etc/init.d/mysql:启停相关脚本
mysql配置文件
- 主要配置文件
- 二进制日志log-bin
- 主从复制
- 错误日志log-error
- 默认是关闭的,记录严重的警告和错误信息,每次启动和关闭的详细信息等。
- 查询日志log
- 默认关闭,记录查询的sql语句,如果开启会降低mysql的整体性能,因为记录日志也是需要消耗系统资源的。
- 数据文件
- 两系统
- windows:D:\devSoft\MySQLServer5.5\data目录下可以挑选很多库
- linux
- 看看当前系统中的全部库后再进去
- 默认路径:/var/lib/mysql
- frm文件:存放表结构
- myd文件:存放表数据
- myi文件:存放表索引
- 两系统
- 如何配置
- windows:my.ini文件
- Linux:/etc/my.cnf文件
- 二进制日志log-bin
mysql逻辑架构介绍
- 和其它数据库相比,MySQL有点与众不同,它的架构可以在多种不同场景中应用并发挥良好作用。主要体现在存储引擎的架构上,插件式的存储引擎架构将查询处理和其它的系统任务以及数据的存储提取相分离。这种架构可以根据业务的需求和时机需要选择合适的存储引擎。
- 从上到下,连接层,服务层,引擎层,存储层
mysql存储引擎
- 查看命令
- 如何用命令查看
- 看你的mysql现在已提供什么存储引擎:show engines;
- 看你的mysql当前默认的存储引擎:show variables like '%storage_engine%';
- 如何用命令查看
- MyISAM和InnoDB
- 阿里巴巴、淘宝用哪个
2. 索引优化分析
性能下降SQL慢
- 执行时间长,等待时间长
- 查询语句写的烂
- 索引失效
- 单值索引
- 复合索引
- 关联查询太多join(设计缺陷或不得已的需求)
- 服务器调优及各个参数设置(缓冲、线程数等)
常见通用的Join查询
索引简介
是什么
优势
- 类似大学图书馆建书目索引,提高数据检索的效率,降低数据库的IO成本。
- 通过索引列对数据进行排序,降低数据排序的成本,降低了CPU的消耗。
劣势
- 实际上索引也是一张表,该表保存了主键与索引字段,并指向实体表的记录,所以索引列也是要占用空间的。
- 虽然索引大大提高了查询速度,同时却会降低更新表的速度,如对表进行INSERT、UPDATE和DELETE。因为更新表时,MySQL不仅要保存数据,还要保存一下索引文件每次更新添加了索引列的字段,都会调整因为更新所带来的键值变化后的索引信息。
- 索引只是提高效率的一个因素,如果你的MySQL有大数据量的表,就需要花时间研究建立最优秀的索引,或者优化查询。
mysql索引分类
单值索引:即一个索引只包含单个列,一个表可以有多个单列索引
唯一索引:索引列的值必须唯一,但允许有空值
复合索引:即一个索引包含多个列
基本语法
mysql索引结构
哪些情况需要创建索引
- 主键自动建立唯一索引
- 频繁作为查询条件的字段应该创建索引
- 查询中与其它表关联的字段,外键关系建立索引
- 频繁更新的字段不适合创建索引,因为每次更新不单单是更新了记录,还会更新索引,加重IO负担
- where条件里用不到的字段不创建索引
- 单键/组合索引的选择问题,who?(在高并发下倾向创建组合索引)
- 查询中排序的字段,排序字段若通过索引去访问将大大提高排序速度
- 查询中统计或者分组字段
哪些情况不需要创建索引
性能分析
MySQL Query Optimizer
MySQL常见瓶颈
- CPU:CPU在饱和的时候一般发生在数据装入内存或从磁盘上读取数据时候
- IO:磁盘I/O瓶颈发生在装入数据远大于内存容量的时候
- 服务器硬件的性能瓶颈:top,free,iostat和vmstat来查看系统的性能状态
Explain
是什么(查看执行计划)
- 使用EXPLAIN关键字可以模拟优化器执行SQL查询语句,从而知道MySQL是如何处理你的SQL语句的。分析你的查询语句或是表结构的性能瓶颈。
能干嘛
- 表的读取顺序
- 数据读取操作的操作类型
- 哪些索引可以使用
- 哪些索引被实际使用
- 表之间的应用
- 每张表有多少行被优化器查询
怎么玩
各字段解释
id
- select查询的序列号,包含一组数字,表示查询中执行select子句或操作表的顺序
- 三种情况:
- id相同,执行顺序由上至下
- id不同,如果是子查询,id的序号会递增,id值越大优先级越高,越先被执行
- id相同不同,同时存在
- 衍生:DERIVED
select_type:
有哪些
查询的类型,主要是用于区别普通查询、联合查询、子查询等的复杂查询
- SIMPLE:简单的select查询,查询中不包含子查询或者UNION。
- PRIMARY:查询中包含任何复杂的子部分,最外层查询则被标记为PRIMARY。
- SUBQUERY:在FROM列表中包含的子查询被标记为DERIVED(衍生),MySQL会递归执行这些子查询,把结果放在临时表里。
- DERIVED:在FROM列表中包含的子查询被标记为DERIVED(衍生)。MySQL会递归执行这些子查询,把结果放在临时表里。
- UNION:若第二个SELECT出现在UNION之后,则被标记为UNION;若UNION包含在FROM子句的子查询中,外层SELECT将被标记为:DERIVED。
- UNION RESULT:从UNION表中获取结果的SELECT。
table:显示这一行的数据是关于哪些表的。
type:
访问类型排序
type显示的是访问类型,是较为重要的一个指标,结果值从最好到最坏依次是:
system>const>eq_ref>ref>fulltext>ref_or_null>index_merge>unique_subquery>index_subquery>range>index>All
显示查询使用了何种类型,从最好到最差依此是:
system>const>eq_ref>ref>range>index>All
system:表只有一行记录(等于系统表),这是const类型的特例,平时不会出现,这个也可以忽略不计。
const:表示通过索引一次就找到了,const用于比较primary key或则unique索引。因为只匹配一行数据,所以很快。如将主键置于where列表中,MySQL就能将该查询转换为一个常量。
eq_ref:唯一性索引扫描,对于每个索引键,表中只有一条记录与之匹配。常见于主键或唯一索引扫描。
ref:非唯一性索引扫描,返回匹配某个单独值的所有行。本质上也是一种索引访问,它返回所有匹配某个单独值的行,然而,它可能会找到多个符合条件的行,所以它应该属于查找和扫描的混合体。
range:只检索给定范围的行,使用一个索引来选择行。key列显示使用了哪个索引。一般就是在你的where语句中出现了between、<、>、in等的查询。这种范围扫描索引扫描比全表扫描要好,因为它只需要开始于索引的某一点,而结束于另一点,不会扫描全部索引。
index:Full Index Scan,index与All区别为index类型只遍历索引树。这通常比All快,因为索引文件通常比数据文件小。(也就是说虽然all和index都是读全表,但index是从索引中读取的,而all是从硬盘中读的)
all:Full Table Scan,将遍历全表以找到匹配的行。
一般来说,得保证查询至少达到range级别,最好能达到ref。
possible_keys:显示可能应用在这张表中的索引,一个或多个。查询涉及到的字段上若存在索引,则该索引将被列出。但不一定被查询实际使用。
key:实际使用的索引。如果为NULL,则没有使用索引。查询中若使用了覆盖索引,则该索引仅出现在key列表中,不会出现在possible_keys列表中。(覆盖索引:查询的字段与建立的复合索引的个数一一吻合)
key_len:表示索引中使用的字节数,可通过该列计算查询中使用的索引的长度。在不损失精确性的情况下,长度越短越好。key_len显示的值为索引字段的最大可能长度,并非实际使用长度,即key_len是根据表定义计算而得,不是通过表内检索出的。
ref:显示索引的哪一列被使用了,如果可能的话,是一个常数。哪些列或常量被用于查找索引列上的值。查询中与其它表关联的字段,外键关系建立索引。
rows:根据表统计信息及索引选用情况,大致估算出找到所需的记录所需要读取的行数。
Extra:包含不适合在其他列中显示但十分重要的额外信息。
Using filesort:说明mysql会对数据使用一个外部的索引排序,而不是按照表内的索引顺序进行读取。MySQL中无法利用索引完成的排序操作成为“文件排序”。
Using temporary:使用了临时表保存中间结果,MySQL在对查询结果排序时使用临时表。常见于排序order by和分组查询group by。
Using index:表示相应的select操作中使用了覆盖索引(Covering Index),避免访问了表的数据行,效率不错!如果同时出现using where,表明索引被用来执行索引键值的查找;如果没有同时出现using where,表明索引用来读取数据而非执行查找动作。
Using where:表明使用了where过滤。
Using join buffer:使用了连接缓存。
impossible where:where子句的值总是false,不能用来获取任何元组。(查询语句中where的条件不可能被满足,恒为False)
select tables optimized away:在没有GROUPBY子句的情况下,基于索引优化MIN/MAX操作或者对于MyISAM存储引擎优化COUNT(*)操作,不必等到执行阶段再进行计算,查询执行计划生成的阶段即完成优化。
distinct:优化distinct操作,在找到第一匹配的元组后即停止找相同值的动作。
热身Case
索引优化
- 索引分析
索引失效(应该避免)
案例(索引失效)
全值匹配我最爱
最佳左前缀法则:
- 如果索引了多列,要遵守最左前缀法则。指的是查询从索引的最左前列开始并且不跳过索引中的列。(==带头大哥不能死,中间兄弟不能断==哈哈哈)
不在索引列上作任何操作(计算、函数、(自动or手动)类型转换),会导致索引失效而转向全表扫描
存储引擎不能使用索引中范围条件右边的列
- 中间兄弟别搞范围,要搞等值
尽量使用覆盖索引(只访问索引的查询(索引列和查询列一致)),减少select *
- 按需取数据,用多少取多少,尽量与索引一致
- Extra中出现了using index很好!
mysql在使用不等于(!=或者<>)的时候无法使用索引会导致全表扫描
is null,is not null也无法使用索引
like以通配符开头(‘%abc…’)mysql索引失效会变成全表扫描的操作
字符串不加单引号索引失效
该问题同问题3,是索引列上做了类型转换!
- VARCHAR类型绝对不能失去单引号
少用or,用它来连接时会索引失效
小总结
优化总结口诀:
全值匹配我最爱,最左前缀要遵守;
带头大哥不能死,中间兄弟不能断;
索引列上少计算,范围之后全失效;
LIKE百分写最右,覆盖索引不写星;
不等空值还有or,索引失效要少用;
VAR引号不可丢,SQL高级也不难!
面试题讲解
一般性建议
- 对于单键索引,尽量选择针对当前query过滤性更好的索引
- 在选择组合索引的时候,当前Query中过滤性最好的字段在索引字段顺序中,位置越靠前越好
- 在选择组合索引的时候,尽量选择可以能够包含当前query中的where字句中更多字段的索引
- 尽可能通过分析统计信息和调整query的写法来达到选择合适索引的目的
3. 查询截取分析
- 分析
- 观察,至少跑1天,看看生产的慢SQL情况。
- 开启慢查询日志,设置阈值,比如超过5秒钟的就是慢SQL,并将它抓取出来。
- explain+慢SQL分析
- show profile
- 运维经理 or DBA,进行SQL数据库服务器参数调优。
- 总结
- 慢查询的开启并捕获
- explain+慢SQL分析
- show profile查询SQL在Mysql服务器里面的执行细节和生命周期情况
- SQL数据库服务器的参数调优
查询优化
永远小表驱动大表,类似嵌套循环Nested Loop
- 优化原则:小表驱动大表,即小的数据集驱动大的数据集。
- 当B表的数据集必须小于A表的数据集时,用in优于exists
- 当A表的数据集必须小于B表的数据集时,用exists优于in
- 注意:A表与B表的ID字段应建立索引。
- EXISTS
- SELECT … FROM table WHERE EXISTS(subquery)
- 该语法可以理解为:将主查询的数据,放到子查询中做条件验证,根据验证结果(TRUE或FALSE)来决定主查询的数据结果是否得以保留。
- 提示
- EXISTS(subquery)只返回TRUE或FALSE,因此子查询中的SELECT *也可以是SELECT 1或SELECT ‘X’,官方说法是实际执行时会忽略SELECT清单,因此没有区别。
- EXISTS子查询的实际执行过程可能经过了优化而不是我们理解上的逐条对比,如果担心效率问题,可进行实际检验以确定是否有效率问题。
- EXISTS子查询往往也可以用条件表达式/其他子查询或者JOIN来替代,何种最优需要具体问题具体分析。
总结
ORDER BY关键字优化
ORDER BY子句,尽量使用Index方式排序,避免使用FileSort方式排序
尽可能在索引列上完成排序操作,遵照索引建的最佳最前缀
如果不在索引列上,filesort有两种算法:
mysql就要启动双路排序和单路排序
双路排序
- MySQL4.1之前是使用双路排序,字面意思就是两次扫描磁盘,最终得到数据。读取行指针和order by列,对他们进行排序,然后扫描已经排好序的列表,按照列表中的值重新从列表中读取对应的数据输出。
- 从磁盘取排序字段,在buffer进行排序,再从磁盘读取其他字段。
取一批数据,要对磁盘进行了两次扫描,众所周知,I\O是很耗时的,所以在mysql4.1之后,出现了第二种改进的算法,就是单路排序
单路排序
- 从磁盘读取查询需要的所有列,按照order by列在buffer对它们进行排序,然后扫描排序后的列表进行输出,它的效率更快一些,避免了第二次读取数据。并且把随机IO变成了顺序IO,但是它会使用更多的空间。
结论及引申出的问题
优化策略
小总结
GROUP BY关键字优化
- group by实质是先排序后进行分组,遵照索引建的最佳左前缀。
- 当无法使用索引列,增大max_length_for_sort_data参数的设置+增大sort_buffer_size参数的设置。
- where高于having,能写在where限定的条件就不要去having限定了。
慢查询日志
是什么
- MySQL的慢查询日志是MySQL提供的一种日志记录,它用来记录在MySQL中响应时间超过阈值的语句,具体指运行时间超过long_query_time值的SQL,则会被记录到慢查询日志中。
- long_query_time的默认值是10,意思是运行10秒以上的语句。
- 由它来查看哪些SQL超出了我们的最大忍耐时间值,比如一条sql执行超过5秒钟,我们就算慢SQL,希望能收集超过5秒的sql,结合之前的explain进行全面分析。
怎么玩
说明
- 默认情况下,MySQL数据库没有开启慢查询日志,需要我们手动来设置这个参数。
- 当然,如果不是调优需要的话,一般不建议启动该参数,因为开启慢查询日志会或多或少带来一定的性能影响。慢查询日志支持将日志记录写入文件。
查看是否开启及如何开启
那么开启了慢查询日志后,什么样的SQL才会记录到慢查询日志里面呢
Case
配置版
日志分析工具mysqldumpslow
批量数据脚本
往表里插入1000w数据
建表
设置参数log_bin_trust_function_creators
创建函数,保证每条数据都不同
创建存储过程
调用存储过程
dept:
DELIMITER ; CALL insert_dept(100, 10);
emp:
DELIMITER ; CALL insert_emp(100001, 500000);
Show Profile
是什么:是mysql提供的可以用来分析当前会话中语句执行的资源消耗情况。可以用于SQL的调优的测量
默认情况下,参数处于关闭状态,并保存最近15次的运行结果
分析步骤
是否支持,看看当前的mysql版本是否支持
开启功能,默认是关闭,使用前需要开启
运行SQL
- select * from emp group by id%10 limit 150000;
- select * from emp group by id%20 order by 5;
查看结果,show profiles;
诊断SQL,show profile cpu, block io for query [上一步前面的问题SQL数字号码];
日常开发需要注意的结论
全局查询日志
4. MySQL锁机制
概述
定义
生活购物
锁的分类
- 从对数据操作的类型(读/写)分
- 读锁(共享锁):针对同一份数据,多个读操作可以同时进行而不会互相影响。
- 写锁(排它锁):当前写操作没有完成前,它会阻断其他写锁和读锁。
- 从对数据操作的粒度分
- 表锁
- 行锁
- 从对数据操作的类型(读/写)分
三锁
- 开销、加锁速度、死锁、粒度、并发性能
- 只能就具体应用的特点来说那种锁更合适
表锁(偏读)
特点:偏向MyISAM存储引擎,开销小,加锁快;无死锁;锁定粒度大,发生锁冲突的概率最高,并发度最低。
案例分析
案例结论
简而言之,就是读锁会阻塞写,但是不会阻塞读。而写锁则会把读和写都阻塞。
表锁分析
- 看看哪些表被加锁了:show open tables;
- 如何分析表锁定:可以通过检查table_locks_waited和table_locks_immediate状态变量来分析系统上的表锁定。
- show status like ‘table%’;
- 这里有两个状态变量记录MySQL内部表级锁定的情况,两个变量的说明如下:
- Table_locks_immediate:产生表级锁定的次数,表示可以立即获取锁的查询次数,每立即获取锁值加1;
- Table_locks_waited:出现表级锁定争用而发生等待的次数(不能立即获取锁的次数,每等待一次锁值加1),此值高则说明存在着较严重的表级锁争用情况。
- 此外,MyISAM的读写锁调度是写优先,这也是MyISAM不适合做写为主表的引擎。因为写锁后,其他线程不能做任何操作,大量的更新会使查询很难得到锁,从而造成永远阻塞。
行锁(偏写)
特点
- 偏向Innodb存储引擎,开销大,加锁慢;会出现死锁;锁定粒度小,发生锁冲突的概率最低,并发度也最高。
- Innodb与MyISAM的最大不同有两点:
- 一是支持事务(TRANSACTION)
- 而是采用了行级锁
由于行锁支持事务,复习老知识
案例分析
建表SQL
行锁定基本演示
无索引行锁升级为表锁
- 如果在更新数据的时候出现了强制类型转换导致索引失效,使得行锁变表锁,即在操作不同行的时候,会出现阻塞的现象。
间隙锁危害
- 什么是间隙锁:当我们用范围条件而不是相等条件索引数据,并请求共享或排他锁时,InnoDB会给符合条件的已有数据记录的索引项加锁;对于键值在条件范围内但并不存在的记录,叫做“间隙(GAP)”。InnoDB也会对这个“间隙”加锁,这种锁机制就是所谓的间隙锁(Next-Key锁)。
- 危害:
- 因为Query执行过程中通过范围查找的话,会锁定整个范围内所有的索引键值,即使这个键值并不存在。
- 间隙锁有一个比较致命的弱点,就是当锁定一个范围键值之后,即使某些不存在的键值也会被无辜的锁定,而造成在锁定的时候无法插入锁定键值范围内的任何数据。在某些场景下这可能会对性能造成很大的危害。
面试题:常考如何锁定一行
- select * from 表 where 某一行的条件 for update;
案例结论
- InnoDB存储引擎由于实现了行级锁定,虽然在锁定机制的实现方面所带来的性能损耗可能比表级锁定会更高一些,但是在整体并发处理能力方面要远远优于MyISAM的表级锁定的。当系统并发量较高的时候,InnoDB的整体性能和MyISAM相比就会有比较明显的优势了。
- 但是,InnoDB的行级锁定同样也有其脆弱的一面,当我们使用不当的时候,可能会让InnoDB的整体性能表现不仅不能比MyISAM高,甚至可能会更差。
行锁分析
如何分析行锁定
通过检查InnoDB_row_lock状态变量来分析系统上的行锁的争夺情况
show status like ‘innodb_row_lock%’;
对各个状态量的说明如下:
- Innodb_row_lock_current_waits:当前正在等待锁定的数量;
- innodb_row_lock_time:从系统启动到现在锁定总时间长度;
- innodb_row_lock_time_avg:每次等待所花平均时间;
- innodb_row_lock_time_max:从系统启动到现在等待最长的一次所花的时间;
- innodb_row_lock_waits:系统启动后到现在总共等待的次数。
对于这5个变量,比较重要的是
- innodb_row_lock_time_avg(等待平均时长)
- innodb_row_lock_waits(等待总次数)
- innodb_row_lock_time(等待总时长)
- 这三项
- 尤其是当等待次数很高,而且每次等待时长也不小的时候,我们就需要分析系统中为什么会有如此多的等待,然后根据分析结果着手制定优化计划。
优化建议
- 尽可能让所有数据检索都通过索引来完成,避免无索引行锁升级为表锁。
- 合理设计索引,尽量缩小锁的范围。
- 尽可能减少索引条件,避免间隙锁。
- 尽量控制事务大小,减少锁定资源量和时间长度。
- 尽可能低级别事务隔离。
页锁
- 开销和加锁时间介于表锁和行锁之间。
- 会出现死锁。
- 锁定粒度介于表锁和行锁之间。
- 并发度一般
5. 主从复制
复制的基本原理
复制的基本原则
- 每个slave只有一个master
- 每个slave只能有一个唯一的服务器ID
- 每个master可以有多个slave
复制的最大问题
- 延时
一主一从常见配置
mysql版本一致且后台以服务运行
主从都配置在[mysqld]结点下,都是小写
- 主机修改my.ini配置文件
从机修改my.cnf配置文件
- 【必须】从服务器唯一ID
- server-id=2
- 【可选】启用二进制日志
- 【必须】从服务器唯一ID
因修改过配置文件,请主机+从机都重启后台mysql服务
主机从机都关闭防火墙
- windows手动关闭
- 关闭虚拟机linux防火墙:service iptables stop
在Windows主机上建立账户并授权slave
在Linux从机上配置需要复制的主机
主机新建库、新建表、insert记录,从机复制
如何停止从服务复制功能
- stop slave;
我的CSDN:https://blog.csdn.net/qq_21579045
我的博客园:https://www.cnblogs.com/lyjun/
我的Github:https://github.com/TinyHandsome
纸上得来终觉浅,绝知此事要躬行~
欢迎大家过来OB~
by 李英俊小朋友