MySQL之性能优化

一、一些概念知识

1、各数据库存储引擎

mysql的存储引擎是针对表进行设置的，一个库的不同表可以设置不同的存储引擎，mysql默认支持多种存储引擎，以适用不同领域的数据库应用需要，主要的几个数据库引擎如下：

a、MyISAM存储引擎

5.5之前默认的存储引擎，不支持事务、不支持外键，表级锁，内存和硬盘空间占用率低，其优势是访问速度快，对事务完整性没有要求，以select、insert为主的应用基本上都可以使用这个引擎；

b、InnoDB存储引擎

5.5之后默认的存储引擎，提供了具有提交、回滚和奔溃恢复能力的事务安全，支持外键并提供了行级锁，其劣势在于写的处理效率相对较低，并且会占用更多的磁盘空间以保留数据和索引；

c、MEMORY存储引擎

使用存于内存中的内容来创建表，MEMORY类型的表数据存于内存访问非常的快，默认使用HASH索引，一旦数据库服务重启或关闭，表中的数据就会丢失；

d、MERGE存储引擎

MERGE存储引擎是一组MyISAM表组合，这些MyISAM表结构完全相同。MERGE表本身没有数据，对MERGE表的CRUD操作都是通过内部的MyISAM表进行的；

2、MySQL的两种索引

a、B-Tree索引

B-Tree 索引是 MySQL 数据库中使用最为频繁的索引类型， 除了 Archive 存储引擎之外的其他所有的存储引擎都支持 B-Tree 索引。不仅仅在 MySQL 中是如此，实际上在其他的 很多数据库管理系统中B-Tree 索引也同样是作为最主要的索 引类型，这主要是因为 B-Tree 索引的存储结构在数据库的 数据检 索中有非常优异的表现。

b、hash索引

Hash 索引结构的特殊性，其检索效率非常高，索引的检索可 以一次定位，不像B-Tree 索引需要从根节点到枝节点，最后 才能访问到页节点这样多次的IO访问，所以 Hash 索引的查 询效率要远高于 B-Tree 索引。 但是hash索引不常用，因为hash索引没有默认排序。

c、索引的相关概念

普通索引： 最基本的索引，没有任何限制。
唯一索引： 与"普通索引"类似，不同的就是：索引列的值必须唯一，但允许有空值。
主键索引： 它是一种特殊的唯一索引，不允许有空值。
全文索引： 仅可用于 MyISAM 表，针对较大的数据，生成全文索引很耗时好空间。
组合索引： 为了更多的提高mysql效率可建立组合索引，遵循”最左前缀“原则。
补充：
聚簇索引(Clustered Indexes)
聚簇索引保证关键字的值相近的元组存储的物理位置也相同（所以字符串类型不宜建 立聚簇索引，特别是随机字符串，会使得系统进行大量的移动操作），且一个表只能 有一个聚簇索引。因为由存储引擎实现索引，所以，并不是所有的引擎都支持聚簇索 引。目前，只有solidDB和InnoDB支持。
非聚簇索引
二级索引叶子节点保存的不是指行的物理位置的指针，而是行的主键值。这意味着通 过二级索引查找行。
InnoDB对主键建立聚簇索引。如果你不指定主键，InnoDB会用一个具有唯一且非空值 的索引来代替。如果不存在这样的索引，InnoDB会定义一个隐藏的主键，然后对其建 立聚簇索引。一般来说，DBMS都会以聚簇索引的形式来存储实际的数据，它是其它二 级索引的基础。
关于 窄索引 和 宽索引

三星索引

d、存储引擎及文件格式比较

sql查询过程：

e、建索引的目的

1. 加快查询速度，当然了，使用索引后查询有迹可循。
2. 减少I/O操作，通过索引的路径来检索数据，不是在磁盘中随机检索。
3. 消除磁盘排序，索引是排序的，走完索引就排序完成

二、sql的优化

优化目标:

1. 根据需求建立索引
2. 每个查询都要使用索引以提高查询效率,至少达到range级别，最好能达到ref；
3. 追求key_len和rows最小；

sql语句的优化可以从以下几种情况考虑：

1、大批量插入数据

• 大批量数据插入空表

  可将表设置成为MyISAM，并通过disable keys将唯一索引关闭；

• 大批量数据插入非空Innodb表，可采取如下措施提高效率：

  1. 导入数据时按照主键顺序排列；
  2. 导入数据前使用set UNIQUE_CHECKS=0,关闭唯一性校验，导入后恢复；
  3. 如果使用了自动提交，建议在导入前执行SET AUTOCOMMIT=0，关闭自动提交，导入后恢复；

2、优化INSERT语句

• 尽量使用多个值表的insert语句，降低连接、关闭的消耗；
• 将索引文件和数据文件分在不同的磁盘上存放；
• 从一个文本文件装入一个表时，使用LOAD DATA INFLIE ,比一般的insert语句快20倍；

3、查询优化

sql优化的大部分内容说的都是查询优化，而查询优化和索引是分不开的。

1. 尽量减少额外的排序，通过索引直接返回有序数据；
2. 尽量少排序，尽量早过滤，避免类型转换。
3. where条件和order by使用相同的索引，并且order by的顺序与索引顺序相同，并且order by的字段都是升序或者都是降序；
4. 尽量只选择查询必要的字段，提高sql性能；
5. 尽量少用join关联表，因为多关联表每次就多扫描一个表，要尽量减少表的关联。
6. 在不得不关联表的时候，在选择目标字段部分，能用join关联查询的不要用子查询，而在where后面的查询条件可以用子查询来缩小范围。
7. 对于包含or的查询语句，如果要利用索引，则or之间的每个条件都必须用到索引，否则应该考虑增加索引；业务允许的话就用 Union all 来代替 or 。例如：select * from user where loginname="xxx" or telephone="xxxx" 不走索引，应该换成 select * from user where loginname="xxx" union all select * from user where telephone="xxx"
8. 优化分页
   在索引上完成排序分页的操作，然后根据主键关联回原表查询所需的其他列。
   把limit查询转换为某个位置的查询；
   例如 Select * from fentrust e limit 4100000, 10 换成 Select * from fentrust e Inner join (select fid from fentrust limit 4100000, 10) a on a.fid = e.fid 效率就高得多。
9. 关联查询时，数据量小的表尽量做主表，查询条件要把筛选结果集小的放前面。
10. 尽可能的使用 varchar/nvarchar 代替 char/nchar ，因为首先变长字段存储空间小，可以节省存储空间，其次对于查询来说，在一个相对较小的字段内搜索效率显然要高些。
11. 尽量使用数字型字段，若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销。这是因为引擎在处理查询和连接时会逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。
12. 应尽可能的避免更新 clustered 索引数据列，因为 clustered 索引数据列的顺序就是表记录的物理存储顺序，一旦该列值改变将导致整个表记录的顺序的调整，会耗费相当大的资源。若应用系统需要频繁更新 clustered 索引数据列，那么需要考虑是否应将该索引建为 clustered 索引。
13. 任何地方都不要使用 select * from t ，用具体的字段列表代替“*”，不要返回用不到的任何字段。
14. 尽量使用表变量来代替临时表。如果表变量包含大量数据，请注意索引非常有限（只有主键索引）。
15. 避免频繁创建和删除临时表，以减少系统表资源的消耗。
16. 临时表并不是不可使用，适当地使用它们可以使某些例程更有效，例如，当需要重复引用大型表或常用表中的某个数据集时。但是，对于一次性事件，最好使用导出表。
17. 在新建临时表时，如果一次性插入数据量很大，那么可以使用 select into 代替 create table，避免造成大量 log ，以提高速度；如果数据量不大，为了缓和系统表的资源，应先create table，然后insert。
18. 尽量避免大事务操作，提高系统并发能力。
19. 尽量避免向客户端返回大数据量，若数据量过大，应该考虑相应需求是否合理。
20. 优先优化高并发的 SQL，而不是执行频率低某些“大”SQL
21. 从全局出发优化，而不是片面调整
22. 尽可能对每一条运行在数据库中的SQL进行 explain

在优化查询sql的时候特别要熟悉那些情况会导致不走索引，归纳总结如下：

4、不使用索引的情况

1. 如果条件中有or,即使其中有条件带索引也不会使用。换言之,就是要求使用的所有字段,都必须建立索引, 我们建议大家尽量避免使用or 关键字

select * from fuser where floginname='xxx' or femail='xx' or fstatus=1

2. 在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致。
3. 如果like是以’%’开始的，则该列上的索引不会被使用。

SELECT * FROM ` fuser ` WHERE ` floginname ` LIKE "%7488%" 

不走索引 – 正则表达式不使用索引,这应该很好理解,所以为什么在SQL中很难看到regexp关键字的原因 – 字符串与数字比较不使用索引;

SELECT * FROM ` fuser` WHERE `floginname` LIKE‘138%' -- 走索引

4. 如果列为字符串，则where条件中必须将字符常量值加引号，否则即使该列上存在索引，也不会被使用;
5. in、not in 、 not exists 、 （<> 不等于 ！=）这些操作符不走索引。 对于连续的数值，能用 between 就不要用 in 了：

如：select id from t where num in(1,2,3)

换成

select id from t where num between 1 and 3 

6. 不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引；例：

SELECT ` famount ` FROM ` fentrust ` WHERE ` famount `+10=30;-- 不会使用索引,因为所有索引列参与了计算

SELECT `famount` FROM `fentrust` WHERE LEFT(`fcreateTime`,4) <1990; -- 不会使用索引,因为使用了函数运算,原理与上面相同 

很多时候用 exists 代替 in 是一个好的选择： select num from a where num in(select num from b) ，用下面的语句替换：

select num from a where exists(select 1 from b where num=a.num) 

7. 应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：select id from t where num is null可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：select id from t where num=0
8. 查询返回的记录数：排序表<40%，非排序表 <7%

5、建议不建立索引的情况

基础表维护时，系统要同时维护索引，不合理的索引将严重影响系统资源（主要表现在CPU和I/O上）；插入、更新、删除数据产生大量db file sequential read锁等待，所以我们只有在必要的时候才建立索引。例如在表数据较大时，作为查询条件和排序字段的列就可以考虑建立索引。
以下是不适合建立索引的情况：

1. 表数据可以确定比较少的不需要建索引
2. 表的碎片较多（频繁增加、删除）
3. 频繁更新的字段不适合建立索引
4. where条件和order by中用不到的字段不适合建立索引
5. 数据重复且发布比较均匀的的字段不适合建索引（唯一性太差的字段不适合建立索引），例如性别，真假值
6. 参与列计算的列不适合建索引
7. 并不是所有索引对查询都有效，SQL是根据表中数据来进行查询优化的，当索引列有大量数据重复时，SQL查询可能不会去利用索引，如一表中有字段sex，male、female几乎各一半，那么即使在sex上建了索引也对查询效率起不了作用。
8. 索引并不是越多越好，索引固然可 以提高相应的 select 的效率，但同时也降低了 insert 及 update 的效率，因为 insert 或 update 时有可能会重建索引，所以怎样建索引需要慎重考虑，视具体情况而定。一个表的索引数最好不要超过6个，若太多则应考虑一些不常使用到的列上建的索引是否有 必要。

三、explain执行计划

MySQL为我们提供了explain命令来分析sql语句的执行效率，通过explain命令获取mysql如何执行select语句的信息，包括在select语句执行过程中表如何连接和连接的顺序；
下面开始explain分析后的结果解析

1、explain的结果解析

1. Id，SQL执行的顺利的标识,SQL从大到小的执行.
2. select_type，就是select类型,具体类型下文会介绍。
3. Table，显示这一行的数据是关于哪张表的.
4. Type，这列很重要,显示了连接使用了哪种类别,有无使用索引；从最好到最差的连接类型为const、eq_reg、ref、range、indexhe和ALL
5. possible_keys，possible_keys列指出MySQL能使用哪个索引在该表中找到行。
6. Key，key列显示MySQL实际决定使用的键（索引）。
7. key_len，使用的索引的长度。在不损失精确性的情况下，长度越短越好
8. Ref，ref列显示使用哪个列或常数与key一起从表中选择行。
9. Rows，rows列显示MySQL认为它执行查询时必须检查的行数。
10. Extra，该列包含MySQL解决查询的详细信息,下面详细.

下面对一些重要属性做详细介绍

a、select_type

1、SIMPLE，简单查询
2、PRIMARY，主查询（多个表关联时）
3、UNION，联合查询
4、DEPENDENT UNION，子查询中的联合查询
5、UNION RESULT，联合的结果集
6、SUBQUERY，第一个子查询
7、 DEPENDENT SUBQUERY，子查询中第一句
8、DERIVED，派生表

b、type

1、system
const联接类型的一个特例。表仅有一行满足条件

2、const
表最多有一个匹配行，它将在查询开始时被读取。因为仅有一行，在这行的列值可被优化器剩余部分认为是常数。const表很快，因为它们只读取一次！

3、eq_ref
对于每个来自于前面的表的行组合，从该表中读取一行。这可能是最好的联接类型，除了const类型。它用在一个索引的所有部分被联接使用并且索引是UNIQUE或PRIMARY KEY。
eq_ref可以用于使用= 操作符比较的带索引的列。比较值可以为常量或一个使用在该表前面所读取的表的列的表达式。

4、.ref
对于每个来自于前面的表的行组合，所有有匹配索引值的行将从这张表中读取。如果联接只使用键的最左边的前缀，或如果键不是UNIQUE或PRIMARY KEY（换句话说，如果联接不能基于关键字选择单个行的话），则使用ref。如果使用的键仅仅匹配少量行，该联接类型是不错的。
ref可以用于使用=或<=>操作符的带索引的列。

5、 ref_or_null
该联接类型如同ref，但是添加了MySQL可以专门搜索包含NULL值的行。在解决子查询中经常使用该联接类型的优化。

6、index_merge
该联接类型表示使用了索引合并优化方法。在这种情况下，key列包含了使用的索引的清单，key_len包含了使用的索引的最长的关键元素。

7、unique_subquery
该类型替换了下面形式的IN子查询的ref。value IN (SELECT primary_key FROM single_table WHERE some_expr)unique_subquery是一个索引查找函数，可以完全替换子查询，效率更高。

8、index_subquery
该联接类型类似于unique_subquery。可以替换IN子查询

9、range
只检索给定范围的行，使用一个索引来选择行。key列显示使用了哪个索引。key_len包含所使用索引的最长关键元素。在该类型中ref列为NULL。

10、index
该联接类型与ALL相同，除了只有索引树被扫描。这通常比ALL快，因为索引文件通常比数据文件小。

11、ALL
对于每个来自于先前的表的行组合，进行完整的表扫描。如果表是第一个没标记const的表，这通常不好，并且通常在它情况下很差。通常可以增加更多的索引而不要使用ALL，使得行能基于前面的表中的常数值或列值被检索出。

c、Extra

这个列可以显示的信息非常多，有几十种。常用如下：
(1).Distinct
一旦MYSQL找到了与行相联合匹配的行，就不再搜索了

(2).Not exists
使用了反连接，先查询外表，再查询内表

(3).Range checked for each Record（index map:#）
没有找到理想的索引，因此对于从前面表中来的每一个行组合，MYSQL检查使用哪个索引，并用它来从表中返回行。这是使用索引的最慢的连接之一

(4).Using filesort
看到这个的时候，查询需要优化。MYSQL需要进行额外的步骤来发现如何对返回的行排序。它根据连接类型以及存储排序键值和匹配条件的全部行的行指针来排序全部行

(5).Using index
列数据是从仅仅使用了索引中的信息而没有读取实际的行动的表返回的，这发生在对表的全部的请求列都是同一个索引的部分的时候

(6).Using temporary
看到这个的时候，查询需要优化。这里，MYSQL需要创建一个临时表来存储结果，这通常发生在对不同的列集进行ORDER BY上，而不是GROUP BY上

(7).Using where
使用了WHERE从句来限制哪些行将与下一张表匹配或者是返回给用户。如果不想返回表中的全部行，并且连接类型ALL或index，这就会发生，或者是查询有问题

(8).firstmatch(tb_name)：
5.6.x开始引入的优化子查询的新特性之一，常见于where字句含有in()类型的子查询。如果内表的数据量比较大，就可能出现这个.

(9).loosescan(m…n)：
5.6.x之后引入的优化子查询的新特性之一，在in()类型的子查询中，子查询返回的可能有重复记录时，就可能出现这个

MySQL执行计划的局限

• EXPLAIN不会告诉你关于触发器、存储过程的信息或用户自定义函数对查询的影响情况
• EXPLAIN不考虑各种Cache
• EXPLAIN不能显示MySQL在执行查询时所作的优化工作
• 部分统计信息是估算的，并非精确值
• EXPALIN只能解释SELECT操作，其他操作要重写为SELECT后查看执行计划

四、MySQL配置文件

1、配置文件

2、缓存配置

原则：写入频繁的数据库，不要开查询缓存。
缓存配置项：
query_cache_size：
Query_cache里的数据又怎么处理呢？首先要把Query_cache和该表 相关的语句全部置为失效，然后在写入更新。那么如果Query_cache
非常大，该表的查询结构又比较多，查询语句失效也慢，一个更新或 是Insert就会很慢，这样看到的就是Update或是Insert怎么这么慢了。 所以在数据库写入量或是更新量也比较大的系统，该参数不适合分配 过大。而且在高并发，写入量大的系统，建议把该功能禁掉。
query_cache_limit：
指定单个查询能够使用的缓冲区大小，缺省为1M。
query_cache_min_res_unit：
默认是4KB，设置值大对大数据查询有好处，但如果你的查询都是小 数据查询，就容易造成内存碎片和浪费。

sort_buffer_size = 2M
connection级参数。太大将导致在连接数增高时，内存不足。
max_allowed_packet = 32M
网络传输中一次消息传输量的最大值。系统默认值 为1MB，最大值是1GB，必须设置1024的倍数。
join_buffer_size = 2M
和sort_buffer_size一样，该参数对应的分配内存也是每个连接独享
tmp_table_size = 256M
默认大小是 32M。GROUP BY 多不多的问题
max_heap_table_size = 256M
key_buffer_size = 2048M
索引的缓冲区大小，对于内存在4GB左右的服务器来说，该参数可设 置为256MB或384MB。
read_buffer_size = 1M
read_rnd_buffer_size = 16M
进行排序查询时，MySql会首先扫描一遍该缓冲，以避免磁盘搜索
bulk_insert_buffer_size = 64M
批量插入数据缓存大小，可以有效提高插入效率，默认为8M

3、Innodb缓存

innodb_buffer_pool_size = 2048M
只需要用Innodb的话则可以设置它高达 70-80% 的 可用内存。一些应用于 key_buffer 的规则有 — 如 果你的数据量不大，并且不会暴增，那么无需把innodb_buffer_pool_size 设置的太大了。
innodb_additional_mem_pool_size = 16M
网络传输中一次消息传输量的最大值。系统默认值 为1MB，最大值是1GB，必须设置1024的倍数。
innodb_log_files_in_group = 3
循环方式将日志文件写到多个文件。推荐设置为3
innodb_lock_wait_timeout = 120
InnoDB 有其内置的死锁检测机制，能导致未完成 的事务回滚。
innodb_file_per_table = 0
独享表空间，关闭

4、连接数

open_files_limit = 10240
允许打开的文件数
back_log = 600
短时间内的多少个请求可以被存在堆栈中
max_connections = 3000
MySQL允许最大的进程连接数，MySQL默认的最大连接数为100，MySQL服务器允许的最大连接数16384
max_connect_errors = 6000
设置每个主机的连接请求异常中断的最大次数，当超过该次数，MYSQL服务器将禁止host的连接请求
thread_cache_size = 300
重新利用保存在缓存中线程的数量
thread_concurrency = 8
thread_concurrency应设为总CPU核数的2倍
thread_stack = 192K
每个线程的堆栈大小，默认值足够大，可满足普通操作。可设置范围为128K至4GB，默认为192KB。

5、线程池相关参数

thread_handling
表示线程池模型。
thread_pool_size
表示线程池的group个数，一般设置为当前CPU核心数目。理想情况下，一个group一个活跃的工 作线程，达到充分利用CPU的目的。
thread_pool_stall_limit
用于timer线程定期检查group是否“停滞”，参数表示检测的间隔。
thread_pool_idle_timeout
当一个worker空闲一段时间后会自动退出，保证线程池中的工作线程在满足请求的情况下，保持 比较低的水平。60秒
thread_pool_oversubscribe
该参数用于控制CPU核心上“超频”的线程数。这个参数设置值不含listen线程计数。
threadpool_high_prio_mode
表示优先队列的模式。
thread_pool_max_threads
限制线程池最大的线程数，超过将无法再创建更多的线程，默认为100000。
thread_pool_high_prio_tickets
最多语序多少次被放入高优先级队列中，默认为4294967295。 只有在thread_pool_high_prio_mode为transactions的时候才有效果

6、慢查询日志

slow_query_log
是否开启慢查询日志，1表示开启，0表示关闭。
log-slow-queries
旧版（5.6以下版本）MySQL数据库慢查询日志存储路径。可以不设置该参数，系统则会默认给一个缺省 的文件host_name-slow.log
slow-query-log-file
新版（5.6及以上版本）MySQL数据库慢查询日志存储路径。可以不设置该参数，系统则会默认给一个缺 省的文件host_name-slow.log
long_query_time
慢查询阈值，当查询时间多于设定的阈值时，记录日志。
log_queries_not_using_indexes
未使用索引的查询也被记录到慢查询日志中（可选项）。
log_output
日志存储方式。log_output=‘FILE’表示将日志存入文件，默认值是’FILE’。log_output='TABLE’表示将日志 存入数据库，这样日志信息就会被写入到mysql.slow_log表中。MySQL数据库支持同时两种日志存储方式 ，配置的时候以逗号隔开即可，如：log_output=‘FILE,TABLE’。日志记录到系统的专用日志表中，要比记 录到文件耗费更多的系统资源，因此对于需要启用慢查询日志，又需要能够获得更高的系统性能，那么建 议优先记录到文件。

五、MySQL主从复制

1、MySQL复制的原理

1. 主库在数据提交时会把数据变更作为事件记录在二进制日志文件Binlog中；可通过sync_binlog控制binlog日志刷新到磁盘的频率；
2. 主库推送二进制日志文件binlog中的事件到从库的中继日志Relay Log，之后从库根据中继日志RelayLog重做数据变更操作，通过逻辑复制达到主从库的数据一致；
3. MySQL通过3个线程来完成主从库之间的数据同步，其中binlog dump线程跑在主库上，I/O线程和sql线程跑在从库上。
4. 当从库启动复制时，首先创建I/O线程连接主库，主库随后创建binlog dump线程读取数据库事件并发送给I/O线程，I/O线程获取到事件数据后更新到从库的中继日志replay log中去，之后从库上的sql线程读取中继日志中更新的数据库事件并应用；
   

2、主从复制配置

log-bin=mysql-bin
[必须]启用二进制日志
server-id=222
[必须]服务器唯一ID，默认是1，一般取IP最后一段
binlog-do-db=DB1
binlog-do-db=DB2 #如果备份多个数据库，重复设置这个选项即可
binlog-do-db=DB3 #需要同步的数据库，如果没有本行，即表示同步所有的数据库
binlog-ignore-db=mysql #被忽略的数据库
rpl_semi_sync_slave_enabled =1 #启用半同步复制
rpl_semi_sync_master_timeout=milliseconds
设置此参数值（ms）,为了防止半同步复制在没有收到确认的情况下发生堵塞，如果Master在超时之前没有收到任何确认 ，将恢复到正常的异步复制，并继续执行没有半同步的复制操作。
rpl_semi_sync_master_wait_no_slave={ON|OFF}
如果一个事务被提交,但Master没有任何Slave的连接。默认情况下，Master会在时间限制范围内继续等待Slave的连接，并 确认该事务已经被正确的写到磁盘上。可以使用此参数选项关闭这种行为，在这种情况下，如果没有Slave连接，Master就 会恢复到异步复制。
master
GRANT REPLICATION SLAVE ON . to ‘mysync’@’%’ identified by ‘q123456’; //一般不用root帐号，“%”表示所有客户端都 可能连，只要帐号，密码正确，此处可用具体客户端IP代替，如192.168.145.226，加强安全。
slave
change master to master_host=‘192.168.145.222’,master_user=‘mysync’,master_password=‘q123456’,
master_log_file=‘mysql-bin.000004’,master_log_pos=308;

补充;
为了方便排查错误和使服务器的效率更高，我们可以安装服务器监控工具，相关的工具有innotop、天兔、PHPadmin等。