MySQL高级

MySQL高级

下载与安装

MySQL下载地址

安装

rpm -ivh MySQL-server-5.5.48-1.linux2.6.x86_64.rpm
rpm -ivh MySQL-client-5.5.48-1.linux2.6.x86_64.rpm

修改初始密码

/usr/bin/mysqladmin -u root password 密码

设置开机自启

chkconfig mysql on

修改配置文件

设置字符集

将初始配置文件复制到/etc下命名为my.cnf

cd /usr/share/mysql/
cp my-huge.cnf /etc/my.cnf

mysql架构

它的架构可以在多种不同的场景中应用并发挥良好的作用，插件式的存储引擎架构将查询处理和其它的系统任务以及数据库的存储提取分离

连接层

最上层的是一些客户端和连接服务，包含本地sock通信和大多数基于客户端/服务端工具实现的类似于TCP/IP的通信。主要完成一些类似于连接处理、授权认证及相关的安全方案。在该层引入了线程池的概念，为通过认证安全接入的客户端提供线程。同样在该层上可以实现基于SSL的安全连接，服务器也会为安全接入的每个客户端验证它所具有的操作权限

服务层

第二层架构主要完成大多数的核心服务功能，如SQL接口，并完成缓存的查询，SQL的分析和优化及部分内置函数的执行，所有跨存储引擎的功能也在这一层实现，如过程、函数等，在该层，服务器会解析查询并创建相应的内部解析树，并对完成相应的优化如确定查询表的顺序，是否利用索引等，最后生成相应的执行操作。如果是select语句，服务器还会查询内部的缓存，如果缓存的空间足够大，这样在解决大量的读操作的环境中能够很好地提升系统性能

引擎层

存储引擎层，真正的负责了MySQL中数据的存储和提取，服务器通过API与存储引擎进行通信。不同的存储引擎具有的功能不同，这样我们可以根据自己的实际需要进行选取

存储层

主要讲数据存储在运行与裸设备的文件系统之上，并完成与存储引擎的交互

存储引擎

MyISAM和InnoDB

索引

MySQL官方对索引的定义：索引是帮助MySQL高效获取数据的数据结构，索引的本质：索引是数据结构
索引可以理解为：排好序的快速查找数据结构
索引本身也很大，所以索引以文件的形式存储在磁盘上
平常所说的索引，一般是指B树结构组织的索引。其中聚集索引，次要索引、复合索引、前缀索引、唯一索引默认都是使用B+树索引，除了B+树索引，还有哈希索引等

索引优势

提高数据检索的效率，降低数据库的IO成本
通过索引列对数据进行排序，降低数据排序的成本，降低了CPU消耗

索引劣势

索引也是一张表，该表保存了主键与索引字段，并指向实体表的记录，所以索引也要占空间
虽然索引大大提高了查询速度，同时却会降低更新表的速度，调整因为更新所带来的键值变化后的索引信息
索引只是提高效率的一个因素，如果MySQL有大量的数据，就需要花时间研究建立最优秀的索引

索引分类

• 单值索引：即一个索引只包含单个列，一个表可以有多个单值索引
• 唯一索引：索引列的值必须唯一，但允许有null值
• 复合索引：即一个索引包含多个列

基本语法

创建

create 【unique】index indexName on mytable(columnName(length));

alter mytable add [unique] index [indexName] on (columnName(length));

删除

drop index [indexName] on mytable;

查看

show index from tableName\G;

索引结构

BTree索引

• 一颗B+树真实的数据存在于叶子节点
• 非叶子节点不存储真实数据，只存储指引搜索方向的数据项
• 3层的B+树可以表示上百万的数据，如果上百万的数据查找只需要三次IO性能提高将是巨大的
  Hash索引
  full-text全文索引
  R-Tree索引

需要创建索引的条件

• 主键自动建立唯一索引
• 频繁作为查询条件的字段
• 查询中与其它表关联的字段，外键关系建立索引
• where条件里用到的字段
• 在高并发下倾向创建组合索引
• 查询中排序的字段，排序字段通过索引访问将大大提高排序速度
• 查询中统计或者分组的字段

不需要创建索引的情况

• 频繁更新的索引不适合创建索引
• 表记录太少
• 数据重复且分布平均的表字段，如果某个数据列包含许多重复的内容，为它建立索引就没有实际效果

性能分析

MySQL Query Optimizer

MYSQL会按自己的优化策略检索，但不见得是DBA认为最优的

MySQL常见瓶颈

• CPU：CPU在饱和的时候一般发生在数据装入内存或从磁盘上读取数据的时候
• IO：磁盘I/O瓶颈发生在装入数据远大于内存容量的时候
• 服务器硬件性能瓶颈：top,free,iostat和vmstat 来查看系统的性能状态

Explain

使用EXplain关键字可以模拟优化器执行SQL查询语句，从而知道MySQL是如何处理SQL语句的
用法：

Explain SQL语句

可以获取的信息：

• 表的读取顺序
• 数据读取操作的操作类型
• 那些索引可以使用
• 那些索引被实际使用
• 表之间的引用
• 每张表有多少行被优化器查询

explain字段解释

id:

• select查询的序列号，包含一组数字，表示查询中执行select子句或操作表的顺序
• 两种情况：
  id相同，执行顺序由上至下
  id不同，如果是子查询，id的序号会递增，id值越大优先级越高

select_type
查询的类型，主要是用于区别普通查询、联合查询、子查询等的复杂查询

关键字	解释
SIMPLE	简单的select查询，查询中不包含子查询或者UNION
PRIMARY	查询中若包含任何复杂的子部分，最外层查询则被标记
SUBQUERY	在select或where列表中包含子查询
DERIVED	在from列表中包含的子查询被标记为DERIVED（衍生）MySQL会递归执行这些子查询，把结果放在临时表里
UNION	若第二个select出现在UNION之后，则被标记为UNION,若UNION包含在FROM子句的子查询中，外层SELECT将被标记为UNION
UNION RESULT	从UNION表获取结果的SELECT

table：数据来自哪张表
type

• 显示查询使用了何种类型，从好到差依次是：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区别为类型只遍历索引树，这通常比ALL快，因为索引文件通常比数据文件小
all	Full Table Scan，将遍历全表以找到匹配的行

一般来说，得保证查询至少达到range级别，最好能达到ref

key

• 实际使用的索引，如果为null，则没有使用索引

• 查询中若使用了覆盖索引，则该索引仅出现在key列表中
  possible_key

• 显示可能应用在这张表中的索引，一个或多个

• 查询涉及到的字段上若存在索引，则该索引将被列出，但不一定被查询实际使用

key_len

• 表示索引中使用的字节数，可通过该列计算查询中使用的索引长度。在不损失精确度的情况下，长度越短越好
• key_len显示的值为索引字段的最大可能长度，并非实际使用长度，即key_len是根据表定义计算而得，不是通过表内检索出的

ref

• 显示索引的那一列被使用了，如果可能，是一个常数，哪些列或常量被用于查找索引列上的值

rows

• 根据表统计信息及索引选用情况，大致估算出找到所需要的记录需要读取的行数
  Extra

• 包含不适合在其它列中显示但十分重要的额外信息

关键字	解释
Using filesort	说明MySQL会对数据使用一个外部的索引排序，而不是按照表内的索引顺序进行读取，MySQL中无法利用索引完成的排序操作称为"文件排序"
Using temporary	使用了临时表保存中间结果，MySQL在对查询结果排序时使用临时表。常见于排序order by和分组查询group by
Using Index	表示相应的select操作使用了覆盖索引，避免访问表的数据行，如果同时出现using where，表明索引被用来执行索引键值的查找，如果没有同时出现using where，表明索引用来读取数据而非执行查找操作
using where	使用了where过滤
using join buffer	使用了连接缓存
impossible where	where子句的值总是false，不能来获取任何元组
select tables optimized away	在没有group by子句的情况下，基于索引优化min/max操作或者对于MyISAM存储引擎优化count(*)，不必等到执行阶段再进行计算，查询执行计划生成的阶段即完成优化
distinct	优化distinct操作，在找到第一匹配的元组后即停止找同样值的动作

索引优化

• 全值匹配我最爱，最左前缀要遵守
• 带头大哥不能死，中间兄弟不能断
• 索引列上少计算，范围之后全失效
• like百分写最右，覆盖索引不写星
• 不等空值还有or，索引失效要少用
• var引号不可丢，SQL高级也不难

索引分析

单表

• 覆盖索引中，范围查询会导致后面的索引失效

EXPLAIN select id
from article
where category_id=1
and comments=1
ORDER BY views
limit 0,1;

show index from article;

CREATE index idx_article_ccv on article(category_id,comments,views);

DROP index idx_article_ccv on article;

CREATE index idx_article_cv on article(category_id,views);

两表

• 左连接右表建索引
• 右连接左表建索引

ALTER TABLE book ADD INDEX Y(card);
EXPLAIN select * from class left join book on class.card=book.card;

三表

alter table phone add index z(card);
alter table book add index Y(card);

EXPLAIN select * from class 
left join book on class.card=book.card
left join phone on book.card=phone.card;

• 后两行的type都是ref，因此索引最好设置在需要经常查询的字段中

join语句的优化

• 尽可能减少join语句中的NestedLoop的循环总次数：“永远用小结果集驱动大结果集”
• 优先优化NestedLoop的内层循环
• 保证join语句中被驱动表上join条件字段已经被索引
• 当无法保证被驱动表的join条件字段被索引且内存资源充足前提下，不要太吝啬joinbuffer的设置

索引失效

1、全值匹配
2、左前缀法则：如果索引了多列，要遵守最左前缀法则，指的是查询从索引的最左前列开始并且不跳过索引中的列
3、不在索引列上做任何操作（计算、函数、类型转换），会导致索引失效而转向全表扫描
4、存储引擎不能使用索引中范围条件范围条件右边的列
**5、尽量使用覆盖索引（只访问索引的查询，索引列和查询列一致，减少select ***
6、MySQL在使用不等于的时候无法使用索引会导致全表扫描
7、is null，is not null 也无法使用索引
8、like以通配符开头MySQL索引失效变成全表扫描

• 使用覆盖索引解决通配符开头索引失效的问题
  9、字符串不加单引号索引失效
  10、少用or，用它来连接时会索引失效

定值、范围还是排序，一般order by是给个范围，group by 基本上都需要排序，会有临时表产生

注意

对于单键索引，尽量选择针对当前query过滤性更好的索引
在选择组合索引时，当前query中过滤性最好的字段在索引字段顺序中，位置越靠左越好
在选择组合索引时，尽量选择可以包含当前query中的where子句中更多字段的索引
尽可能通过分析统计和调整query的写法来达到选择合适索引的目的

查询截取分析

• 慢查询的开启并捕获
• explain+慢SQL分析
• show profile查询SQL在MySQL服务器里面的执行细节和生命周期
• SQL数据库服务器的参数调优

查询优化

• 优化原则：小表驱动大表，即小的数据集驱动大的数据集

select * from A where id in (select id from B)
等价于
for select id from  B
for select * from A where A.id=B.id

当B表的数据集小于A表的时候，用in优于exists

select * from A where exists (select 1 from B where B.id=A.id)
等价于
for select * from A
for select * from B where B.id=A.id

当A表的数据集小于B表的数据集，用exists优于in

order by关键字优化

• order by子句，尽量使用index方式排序，避免使用filesort方式排序
• 尽可能在索引列上完成排序操作，遵照索引建的最佳左前缀
• 如果不在索引列上，filesort有两种算法：MySQL就要启动双路排序和单路排序
  双路排序
  MySQL4.1之前是使用双路排序，字面意思是两次扫描磁盘，最终的导数据，读取行指针和order by列，对它们进行排序，然后扫描已经排好序的列表，按照列表中的值重新从列表中读取
  从磁盘取排序字段，在buffer进行排序，再从磁盘取其它字段
  取一批数据，要对磁盘进行两次扫描，I\O很耗时，4.1之后出现了第二种改进算法，单路排序
  单路排序
  从磁盘读取查询需要的所有列，按照order by列在buffer对它们进行排序，然后扫描排序后的列表进行输出，它的效率更快，避免了第二次读取数据。并且把随机IO变成了顺序IO，但它会使用更多的空间，因为它把每一行都保存在内存中了
  缓存问题
  在sort_buffer中，单路比双路占用很多的空间，因为单路是把所有字段都取出，所以有可能取出的数据总大小超出了sort_buffer的容量，导致每次只能取sort_buffer容量大小的数据，进行排序（创建tmp文件，多路合并），排完再取sort_buffer容量的大小，出现多次I\O
• 优化策略

增大sort_buffer_size参数的设置
增大max_length_for_sort_data的参数

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秒
• 结合explain进行全面分析

慢查询日志查看与开启

• MySQL默认情况下没开启慢查询日志
• 一般不建议开启，会影响性能

查看

show variables like '%slow_query_log%'；

开启

set global slow_query_log=1;

设置慢的阈值时间

set global long_query_time=3；
修改后需要重新连接或新开一个会话才能看到修改值

查看阈值时间

show global variables like 'long_query_time';

查询当前系统中有多少条慢查询记录

show global status like '%slow_queries%';

如果要永久生效，必须修改配置文件my.cnf

【mysqld】下配置
slow_query_log=1;
slow_query_log_file=/var/lib/mysql/slow.log
long_query_time=3;
log_output=FILE

日志分析工具mysqldumpslow

命令	含义
s	表示按照何种方式排序
c	访问次数
l	锁定时间
r	返回记录
t	查询时间
al	平均锁定时间
ar	平均返回记录数
at	平均查询时间
t	返回前面多少条数据
g	后边搭配一个正则匹配模式，大小写不敏感

得到返回记录集最多的10个SQL

mysqldumpslow -s r -t 10 /var/lib/mysql/localhost-slow.log

得到访问次数最多的10个SQL

mysqldumpslow -s c -t 10 /var/lib/mysql/localhost-slow.log

得到按照时间排序的前10条里含有左连接的查询语句

mysqldumpslow -s t -t 10 -g "left join" /var/lib/mysql/localhost-slow.log

建议在使用这些命令时结合| 和more使用

mysqldumpslow -s r -t 10 /var/lib/mysql/localhost-slow.log | more

批量数据脚本

创建函数，假如报错：this function has none of determini…

#由于开启了慢查询日志，必须为function指定一个参数
show variables like 'log_bin_trust_function_creators';
set global log_bin_trust_function_creators=1;

随机产生字符串

set global log_bin_trust_function_creators=1;
delimiter $$
create FUNCTION rand_string(n int) returns varchar(255)
BEGIN
	DECLARE chars_str VARCHAR(100) DEFAULT 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ';
	DECLARE return_str varchar(255) DEFAULT '';
	DECLARE i int DEFAULT 0;
	WHILE i<n do
	set return_str=CONCAT(return_str,SUBSTRING(chars_str,FLOOR(1+RAND()*52),1));
	set i=i+1;
	end WHILE;
	return return_str;
END $$

select rand_string(20);

随机产生范围数字

delimiter $$
create function rand_num() RETURNS int(5)
begin 
	DECLARE i int DEFAULT 0;
	set i=FLOOR(100+RAND()*10);
	RETURN i;
END $$

select rand_num();

存储过程批量插入数据

delimiter $$
create PROCEDURE insert_emp(in start int(10),in max_num int(10))
begin 
DECLARE i int DEFAULT 0;
set autocommit=0;
repeat
set i=i+1;
INSERT into emp(empno,ename,job,mgr,hiredate,sal,comm,deptno)
VALUES((start+i),rand_string(6),'salesman',0001,curdate(),2000,400,rand_num());
UNTIL i=max_num
end repeat;
commit;
end $$

show profile

• mysql提供可以用来分析当前会话中语句执行的资源消耗情况，可以用于SQL调优的测量
• 默认情况下，参数处于关闭状态，并保存最近15次的运行结果

分析步骤

1、查看是否支持

show global variables like 'profiling';

2、开启，默认是关闭

set global profiling=on;

3、运行SQL

select * from emp group by id%10 limit 150000;

select * from emp group bu id%20 order by 5;

4、查看结果

show profiles;

5、诊断SQL

show profiles cpu,block io for query n;

• 参数

type	含义
ALL	显示所有的开销信息
BLOCK IO	显示块IO相关开销
CONTEXT SWITCHES	上下文切换相关开销
CPU	显示CPU相关开销
IPC	显示发送和接受相关开销信息
MEMORY	显示内存相关开销信息
PAGE FAULTS	显示页面错误相关开销信息
SOURCE	显示和Source_function,Source_file,Source_line相关的开销信息
SWAPS	显示交换次数相关开销信息

6、日常开发需要注意的结论

• coverting HEAP to MyISAM:查询结果太大，内存都不够用了往磁盘上搬了
• Creating tmp table:创建临时表-拷贝数据到临时表，用完再删除
• Coping to tmp table on disk:把内存中临时文件复制到磁盘，危险
• locked

全局查询日志

不要在生产环境开启这个功能
配置启用

在my.cnf中
#开启
general_log=1
#记录日志文件路径
general_log_file=/path/logfile
#输出格式
log_output=FILE

编码启用

set global general_log=1;
set global log_output='TABLE';

编写的SQL语句，会记录到mysql库里的general_log表，使用如下命令查看

select * from mysql.general_log;

mysql锁机制

锁是计算机协调多个进程或线程并发访问某一资源的机制
在数据库中，除传统的计算资源（如CPU、RAM、i/O等）的争用外，数据也是一种供许多用户共享的资源，如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一个问题，锁冲突也是影响数据库并发访问性能的一个重要因素。从这个角度来说，锁对数据库而言尤其重要，也更加复杂

锁的分类

按数据操作的类型（读\写）
读锁（共享锁）：对同一份数据，多个读操作可以同时进行二不会互相影响
写锁（排它所）：当前写操作没完成，会阻断其它写锁和读锁
按数据操作的粒度分
表锁
行锁

三锁（表、行、页）

开销、加锁速度、死锁、粒度、并发性能只能就具体应用特点来说哪种锁更合适
InnoDB存储引擎由于实现了行级锁，虽然在锁机制的实现方面所带来的性能损耗可能比表锁高一些，但是在整体并发处理能力方面远远优于MyISAM的表级锁，当系统并发量较高的时候，InnoDB的整体性能有较大优势。
InnoDB的行级锁同样也有脆弱的一面，当使用不当时（行锁升级为表锁），会让InnoDB的整体性能表现比MyISAM差

表锁（偏读）

偏向MyISAM存储引擎，开销小，加锁快，无死锁，锁粒度大，发生锁冲突的概率最高，并发度低
读阻塞写

建表

CREATE TABLE mylock(
	id int not null PRIMARY KEY auto_increment,
	name varchar(20)
)ENGINE myisam;

INSERT INTO mylock(name)VALUES('a'),('b'),('c'),('d'),('e');

select * from mylock;

手动加锁

lock table 表名 read|write;

查看表的加锁情况

show open tables;

表锁分析

通过检查table_locks_waited和table_locks_immediate状态变量莱分析系统上的表锁定

show status like 'table%';

table_locks_immediate:产生表级锁定的次数，表示可以立即获取锁的查询次数，每立即获取锁值加1
table_locks_waited:出现表级锁定争用而发生等待的次数，此值高说明严重的表级争用情况
此外，MyISAM的读写锁调度是写优先，这也是MyISAM不适合做写为主的引擎。因为写锁后，其它线程不能做任何操作，大量的更新会使查询很难得到锁，从而造成永远阻塞

行锁（偏写）

偏向InnoDB存储引擎，开销大，加锁慢，会出现死锁，锁粒度小，发生锁冲突的概率最低，并发度也最高
InnoDB与MyISAM的最大不同有两点：一是支持事务，二是采用了行级锁

并发事务处理的问题

• 更新丢失：两个进程并发更新数据，数据被覆盖
• 脏读：事务A读取到事务B未提交的数据
• 不可重复读：事务A读取到事务B已经提交的修改数据
• 幻读：事务A读取到事务B提交的新增数据，不符合隔离性

事务隔离级别

隔离级别	读数据一致性	脏读	不可重复读	幻读
未提交读（read uncommitted）	最低级别，只能保证不读取物理损坏的数据	是	是	是
已提交读（read committed）	语句级	否	是	是
可重复读（repeatable read）	事务级	否	否	是
可序列化（serializable）	最高级别，事务级	否	否	否

查看当前数据库的事务隔离级别

show variables like 'tx_isolation';

建表SQL

CREATE TABLE test_innodb_lock(a int(11),b varchar(16))ENGINE=INNODB;

INSERT INTO test_innodb_lock values(1,'b1');
INSERT INTO test_innodb_lock values(2,'b2');
INSERT INTO test_innodb_lock values(3,'300');
INSERT INTO test_innodb_lock values(4,'4000');
INSERT INTO test_innodb_lock values(5,'5000');
INSERT INTO test_innodb_lock values(6,'600');
INSERT INTO test_innodb_lock values(7,'700');

CREATE INDEX test_innodb_a_ind on test_innodb_lock(a);
CREATE INDEX test_innodb_lock_b_ind on test_innodb_lock(b);

无索引行锁升级为表锁

字段b为varchar 类型，类型转换导致索引失效，行锁升级为表锁，并且只是当前索引的锁变为表锁

间隙锁的危害

间隙锁：当我们用范围条件而不是相等条件检索数据时，InnoDB会给符合条件的已有数据记录的索引项加锁，对于键值在条件范围内但并不存在的记录，叫做“间隙（GAP）”，InnoDB也会对这个间隙加锁，这种锁机制就是所谓的间隙锁（Next-Key锁）
危害：因为Query执行过程中通过范围查找，会锁定整个范围内所有的索引键值，即使这个键值不存在，造成在锁定的时候无法插入锁定键值范围内的任何数据。

如何锁定一行

select * from 表名 where id=1 for update;

行锁分析

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	系统启动后到现在总共等待的次数

当等待次数很高时，而且每次等待时长也很大，就需要进行优化

优化建议

• 尽可能让所有数据检索都通过索引来完成，避免无索引行锁升级为表锁
• 合理设计索引，尽量缩小锁的范围
• 尽可能较少检索条件，避免间隙锁
• 尽量控制事务大小，减少锁定资源量和时间长度
• 尽可能低级别事务隔离

页锁

• 开销和加锁时间介于表锁和行锁之间，会出现死锁，锁定粒度介于表锁与行锁之间，并发度一般

主从复制

复制的最大问题-延迟

复制基本原理

MySQL复制分三步：

• master将改变记录到二进制日志（binary log），这些记录过程叫二进制日志时间，binary log events
• slave将master的binary log events拷贝到它的中继日志（relay log）
• slave重做中继日志的事件，将改变应用到自己的数据库中。MySQL复制是异步串行化

复制基本规则

• 每个slave只有一个master
• 每个slave只能有一个唯一的服务器ID
• 每个master可以有多个slave

一主一从配置

MySQL版本一致
主从都配置在【mysqld】节点下
主机修改my.ini配置文件

#主服务器唯一ID【必须】
server-id=1
#启用二进制日志【必须】
log-bin=自己本地路径\mysqlbin
#启动错误日志
log-err=本地路径\mysqlerr
#根目录【可选】
basedir=自己本地路径
#临时目录【可选】
tmpdir=自己本地路径
#数据目录【可选】
datadir=自己本地路径\Data\
#主机，读写都可以
read-only=0
#设置不要复制的数据库
binlog-ignore-db=mysql
#设置需要复制的数据库【可选】
binlog-do-db=需要复制的主数据库名字

从机修改my.cnf配置文件

找到
log-bin=mysql-bin
server-id=2

主从数据库重启
都关闭防火墙

service iptables stop

在Windows主机上建立账户并授权slave

CREATE USER 'slave123'@'192.168.103.%' IDENTIFIED BY '123456';#创建用户
GRANT REPLICATION SLAVE ON *.* TO 'slave123'@'192.168.103.%';#授权
flush privileges; 
查看主机状态
show master status;

从数据库

change master to master_host='192.168.43.130',
master_user='slave123',
master_password='123456',
master_log_file='mysql-bin.000004',
master_log_pos=2315;

开启从服务

start slave；

出现两个Yes证明成功