mysql架构
mysql 存储引擎 show engines; 查看数据引擎
查看当前默认的存储引擎
show VARIABLES like '%STORAGE_ENGINE%'; 
| 对比项 | MyISAM | INNODB |
|---|---|---|
| 主外键 | 不支持 | 支持 |
| 事务 | 不支持 | 支持 |
| 行表锁 | 表锁，即使操作一张表也会锁住整个表，不适合高并发的操作 | 行锁，操作时只锁某一行，不对其他行有影响。适合高并发的操作 |
| 缓存 | 只缓存索引，不缓存真实数据 | 不仅缓存索引还要缓存真实数据，对内存的要求较高，而且内存大小对性能有决定性的影响 |
| 表空间 | 小 | 大 |
| 关注点 | 性能 | 事务 |
| 默认安装 | y | y |
阿里巴巴大部分mysql数据库其实使用的是percona的圆形加以修改。
AliSql+AliRedis
Percona为Mysql数据库服务器进行了改进，在功能和性能上较Mysql有显著的提升。该版本提升了再高并发下的InnoDB的性能，为DBA提供一些飞上有用的性能诊断工具，另外还有更多地参数和命令来控制服务器行为。改公司新建了一款xtradb完全可以替代innodb，并在性能和并发上做的更好。
索引优化
性能下降sql慢：
执行时间长
等待时间长
原因：1.索引失效 单值索引： create index idx_user_name(索引名) on user（name)
复合索引： create index idx_user_nameEmail on user(name,email)
2.关联查询太多join
机器读sql顺序
sql解析
七种连接：
左外连接，左表的全部
右外连接，右表全部
内连接，共有部分查交集
左连接 左表的私有部分（这时需要将这部分相同数据去掉，去除的条件就是B.key IS NULL ）
右连接 右表的私有部分
全连接 （Mysql中不支持写法） 全部数据
但是！MySQL中并不支持这种写法，所以只能通过别的方法。
A、B的所有也就是A的独有、B的独有 和A、B的共同拥有的数据
Mysql中可以使用：
select * from Table A left join Table B on A.Key = B.Key (找出A的所有)
union (去重)
select * from Table A right join Table B on A.Key = B.Key （找出B的所
全外连接 ：左右表的共有数据之外的数据查询
筛选出对于A表而言B为空，对于B表而言A为空的
MySQL中也不支持这种写法，所以只能通过别的方法。
其实全外连接也就是A的独有+B的独有
Mysql语法： select * from Table A left join Table B on A.Key = B.Key where B.Key is null (找出A的独有)
union (去重)
select * from Table A right join Table B on A.Key = B.Key where A.Key is null （找出B的独有)
索引： 是帮助Mysql高效获取数据的数据结构 索引是数据结构
排好序的快速查找数据结构
一般来说，索引本身也很大，不能全不存在内存中，往往以索引文件的形式存储磁盘上
一般指b树结构组织的索引。索引的目的在于提高查询效率，可以类比字典
在数据之外。数据库系统还维护着满足特定查找算法的数据结构，这些数据结构以某种反说方式（指针）指向数据，这样就可以在数据结构上实现高级查找算法，这种数据结构，称为索引。
更新的时候数据要改，索引也要改，所以更新慢
索引的分类： 聚集索引 、次要索引 、复合索引、覆盖索引、前缀索引、唯一索引默认都是使用B+树索引，除了b+树索引，还有哈希索引等。
实际上索引也是一张表，该表保存了主键和索引字段，并指向实体表的记录，所以索引列也是要占用空间的
索引优势：提高检索效率，降低数据库的IO成本，进行了排序，降低了CPU的消耗。
劣势：1.实际上索引也是一张表，该表保存了主键和索引字段，并指向实体表的记录，所以索引列 也是要占用空间的
2.降低了更新表的速度，更新表时不仅要保存数据，还要保存索引
索引分类： 一张表最好不要超过五个索引
单值索引：一个索引只包含单个列，一个表可以有多个单列索引
唯一索引：索引列值必须唯一，但是允许有空值。
复合索引：一个索引包含多个列
基本语法：
创建 ：create [UNIQUE] INDEX indexName on myTable(columname(length))
alter mytable ADD[UNIQUE] INDEX[INDEXNAME] on(columnname(length))
删除 ： DROP INDEX[indexName] on tableName;
查看 ：SHOW INDEX FROM table_name\G
四种索引的添加
Alter table table_name add primary key (column_list) ;添加主键索引
Alter table table_name add unique index_name (column_list);添加唯一索引
Alter table table_name add index index_name (column_list);普通索引
Alter table table_name add FULLTEXT index_name (column_list);索引为FULLTEXT,用于全文索引
索引结构 ：
BTree索引 ： 检索原理
Hash索引 :
full-text 全文索引：
R-tree索引
哪些情况下建立索引 ：
1.主键
2.频繁查找的
3.查询中与其他表关联的字段外键
4.频繁更新的不适合建索引
5.where 条件里用不到的字段不创建索引
6.单键、组合索引的选择在高并发下创建组合索引
7.查询中的排序字段，排序字段若通过索引访问将大大提高效率
8.查询中统计或者分组的字段（分组必排序）
不创建索引
1.表记录太少
2.经常增删改的表
数据重复且分布均匀的表字段，因此应该只为最经常查询和经常排序的数据建立索引
3.如果某个数据列包含太多重复的内容，就不适合建立索引
性能分析：
Mysql Query Optimizer :
1.Mysql中有转么负责优化select语句的优化器模块，主要功能：通过计算分析系统中收集到的统计信息，为客户端请求的query提供他认为最优的数据检索方式
2.当客户端想Mysql请求一条query,命令解析器模块完成请求分类，区别出是select 并转发给Mysql Query Optimizer时首先会对整条Query进行优化，处理掉一些常量表达式的预算直接换成常量值，并对query中的查询条件进行简化和转换。如去掉一些无用的或者显而易见的一无用的条件然后分析Query中的Hint信息，看显示Hint信息是否可以完全确定改Query的执行计划如果没有Hint或者Hint信息还不足以完全确定执行计划。则会读取对象的统计信息，根据query进行计算分析，然后再得出最后的执行计划。
Mysql的常见瓶颈：
CPU :cpu在饱和的时候一般发生在数据装入内存或者从磁盘上读取数据的时候
IO:磁盘I/O瓶颈发生在装入数据远大于内存容量的时候
服务器硬件的性能瓶颈：top,free，iostat和vmstat来查看系统的性能状态
查看执行计划 ： explain 模拟优化器执行过程
explain +sql : 作用
1.表的读取顺序
2.数据读取操作的操作类型
3.哪些索引可以使用
4.哪些索引被实际引用
5.表之间的引用
6.每张表有多少行被优化器查询
执行计划包含的信息：
表的读取顺序：id 可以解决小标驱动大表
1.id: select 查询的序列号，包含一组数字，表示查询中执行select子句或者操作表的顺序
1.id相同，执行顺序由上而下
2.如果是子查询，id的序号会递增，id越大优先级越高，越先执行
3.id如果相同，可以认为是一组，从上往下顺序执行；所有组中，id值越大，优先级越高，越先执行。
数据读取操作的操作类型
select__type :查询的类型主要用于区别普通查询，联合查询，子查询等的复杂查询
1.simple :普通查询 简单的select 查询，查询中不包含子查询和union查询
2.primary:查询中若包含人和复杂的子查询，最外层查询则被标记为
3.subquery:在select或者where列表中包含了子查询
4,DERIVED:在from列表中包含的子查询被标记为、DERIVED(衍生)Mysql会递归的执行这些子查询，把结果放在临时表里（临时表会增加系统负担，但有时候不得不用）
5.union 若第二个select出现在union 之后，则被标记为union;如果union包含在from的子查询中，外层select 将被标记为DERIVED
6.union Result 从union 表里获取结果的select
table:数据是哪张表的
type :访问类型
1.System：表记录只有一行：这是const的特例，平时基本不会出现，可以忽略不计
2.const：通过索引一次就照到了，用于比较primary key或者unique索引。因为职匹配一行数据，所以很快。如将主键置于where列表中。Mysql就能将该查询转换为一个常量
3.eq_ref：唯一性索引扫描，对于每个索引键表中之友一条记录与之扫描，常用于主键或者唯一性扫描。
4.ref：非唯一性索引扫描，返回匹配的某个单独值的所有行。本质上也是一种索引访问，他返回的所有匹配某个单独值的行，然而他可能会找到多个符合条件的行，所以他应该属于查找和扫描的混合体
5 range：只检索给定范围的行，使用一个索引来选择行。key列显示使用了哪个索引。一般就在你的where语句出现了between < ,> ,in等的查询
这种范围要比全表扫描好因为她只需要开始于索引的某一点，而结束于另一点，不用扫描全部索引
6.index：index与all区别为index 类型只遍历索引树，这通常比all快。因为索引文件通常比数据文件小。也就是说all和index虽然都是读全表，但是是从索引索引中读的，all是从磁盘中读取的
7.all：全表扫描
一般得保证查询至少到达ref或者range级别
possible_keys
显示可能应用在这张表的索引，一个或者多个，查询涉及到的字段上若存在索引，则该索引将被列出，但是不一定被查询实际使用。
key：实际使用的索引，查询中若使用了覆盖索引，则索引仅仅出现在覆盖索引中
key_len:表示索引中使用的字节数。可以通过该列计算查询中使用的索引的长度，在不损失精度的情况下，长度越短越好。key_len限制的值为索引字段的最大可能长度，并非实际使用长度，key_len 是通过表定义而计算的，不是通过表内检索得出的
ref:显示索引的哪一列被使用了如果可能的话，是一个常数，那些列或者常量被用于查找索隐列上的值。查询中与其他表关联的字段，外键关系建立索引。
row:每张表被多少张优化器查询过，根据表统计信息及索引的选用情况，大致估计出查到所需的记录索要读取的行数。
extra : 包含不适合在其他列中显示但是又十分重要的信息
using filesort: mysql 会对数据使用一个外部的索引排序，而不是按照表内的索引进行读取。Mysql中无法利用索引完成的排序叫做文件排序
USing temporary: 使用了临时表保存中间结果，Mysql在对结果排序时使用了临时表，常用语orderby 和group by（临时表的创建和回收是比较消耗性能）
using index: (推荐) 表示相应的select 操作中使用了覆盖索引避免了访问表的数据行，效率不错！如果同时出现了usingwhere 表名索引被用来执行索引键值的查找；
如果没有出现usingwhere（部分索引匹配） 表明索引用来读取数据而非执行查找动作
usingwhere：
using join bufffer :使用了连接缓存
impossible where : where 的子句的值总是false,不能用来获取任何元组
select tables optimized away: 在没有group by 子句的情况下，基于索引优化min/max操作或者对于MyISAM存储引擎优化count(*) 操作，不必等到执行阶段再进行计算，查询执行计划的生成阶段即完成优化
distinct:优化distinct 找到第一个匹配的时候就停止查找同样值的优化。
覆盖索引：就是select 的数据列只用从索引中就能取到，不必读取数据行，Mysql 可以利用索引返回select 列表中的字段，而不必根据索引再次读取数据文件。换句话说就是列要被所建立的索引覆盖。如果要使用覆盖索引，一定要注意select 列表中的列，如果将所有字段作为索引，会导致性能下降。
索引的单表优化：
1.范围以后的索引会失效,所以要避免
多表优化：
1.左右外连接，相反加索引，left join条件用于确定如何从右表搜索行，左边一定都有，所以右边是关键，一定要建立索引。
三表优化：
索引设置在需要经常查询的字段中，小表驱动大表，减少IO访问
优先优化内层循环
保证join语句上的被驱动表的条件字段已经被索引
当无法保证被驱动表的ｊｏｉｎ条件字段被索引且内存资源充足的前提下，不要太吝啬joinbuffer的设置。
索引优化：
索引失效应该如何避免：
1.全值匹配
2.最佳左前缀
3.不在索引上做任何操作
4.存储引擎不能使用索引条件中范围条件右边的列
5，尽量使用覆盖索引，减少select *
6.mysql在使用！= 或者 > < 的时候无法使用索引会导致全表扫描
7.is null,is not null也无法使用索引
8.like 以‘%’开头也会索引失效
9.字符串不加单引号也会索引失效
10.少用or 用它来连接时索引失效
解决like索引百分号时候不被使用的方法
1.推荐覆盖索引解决
order by 如果不按照索引使用，会造成文件内排序usingfilesort 但是如过果前面索引到了，即使order by 索引顺序颠倒也不会文件内排序
select * from test where c1 ='1' and c2 = '2' and c5 = '5' order by c3,c2 荏苒不会文件内排序，因为此时某个排序的值已经唯一(c2)
group by :分组之前必须排序。会有临时表产生
总结，定值范围还是排序，一般order by 是给个范围。
索引优化建议：
对于单值索引，尽可能选择针对当前query过滤性更好的索引
对于组合索引，当前query 中过滤性更好的字段在索引字段顺序中，位置越靠前越好
在选择组合索引的 时候，尽量选择呢能够包含当前的query中的where子句中更多字段的 索引
尽可能通过分析统计信息和调整query的写发来大道选择组合索引的目的
查询截取分析
分析：
1.观察，至少跑一天，看看生产的慢sql情况
2.开启慢查询日志，设置阈值，比如超过5秒的慢sql,并将它抓取出来
3.explain +慢sql 分析
4，show profile 分析力度和explain
5.运维经理或者DBA进行sql数据库的参数优化
总结
1.慢查询的开启并捕获
2.explain + 慢sql 分析
3.show profile查询sql在mysql 服务器里面的执行细节和生命周期情况
4.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.
用exists 改写 in
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
实际上就是将主查询的数据放到子查询中做条件验证，根据验证结果（TRUE或者FALSE） 来决定主查询的数据结果是否得以保留
exists 只返回True或者false ,因此子查询中的select * 和select 1 没差别、
exists 子查询的实际执行过程可能经过了优化而不是我们理解上的逐条对比
exists 子查询往往也可以用条件表达式子查询或者join 来代替，何种最优需要具体的问题具体分析。
优化原则：1.小表驱动大表
2.order by优化：避免using filesort Mysql支持两种方式的排序，filesort和index ,index效率高。他指Mysql扫描索引本身完成排序，firesort效率低，order by默认升序。order by 满足两个情况，会使用index 方式排序 1.order by 语句使用索引最左前列 2.使用where子句与order by子句条件列组合满足索引最左前列
优化orderby 尽量使用index 方式排序，避免filesort 方式排序 2.尽量在索隐列上完成排序操作，遵照索引建立最佳左前缀
3.如果不在索引列上，filesort 有两种算法：mysql 启动双路排序和单路排序
单路排序：从磁盘读取查询所需要的所有列，按照order by 列在buffer 对他们进行排序，然后扫描排序后的列表进行输出，效率更快，避免了二次读取数据，并且把随机I/O变成了顺序I/O,但是他会使用更多地空间，因为他把每一行都保存在内存中了。
（单路算法可能会失效，sort _bufffer大小不合适会导致取多次，超出之后，会创建临时文件，然后对文件进行合并排序，导致多次I/O）
双路排序：4.1之前，双路排序，扫两次磁盘，获得行指针和orderby列，他们进行排序
优化策略：
增大sort_buffer_size参数的设置
增大max_length_for_sort_data参数的设置
提高order by 的速度
1.不要用select *
1.1当query的字段大小总和小于max_length_for_sort_data,而且排序字段不是text/blob类型时，会采用单路排序，否则采用多路排序。
1.2.两种算法的数据都有可能超出sort_buffer的容量，超出之后，会创建临时文件进行合并排序，导致多次I/O但是单路排序的算法风险会更大一点，所以要提高sort_buffer_size
2.尝试提高sort_buffer_size
不管采用那种算法，提高这个参数都会提高效率，当然适量
3.尝试提高max_length_for_sort_data
提高这个参数，会增加用改进算法的概率，但是如果设置的太高，数据的总容量超出sort_buffer 的概率增大，明显症状是高的磁盘I/O和低的处理器使用率。
如果where使用的最左前缀定义为常量，则orderby能使用索引
不能使用索引排序：
排序不一致 有的升有的降
丢失前缀索引
对于排序来说多个相等条件也是范围查询
排序中出现不是索引的一部分
3.group by
等同于orderby 实质上是先排序后分组
where高于having，能写在where 限定的条件就不要去having 限定了
慢查询日志：日志记录，记录响应时间超过阈值的sql语句。默认long_query_time 的大小是10s.默认不开启，需要手动设置这个参数
show variables like ' %slow_query_log%'
开启 ：set global show_query_log = 1;只对当前数据库有效，重启会失效
永久生效：修改my.cnf配置文件 增加或者修改参数 slow_query_log 和slow_query_log_file后重启mysql
slow_query_log = 1;
slow_query_log_file = /var/lib/mysql/atguigu-slow.log;文件名字自定义
使用命令
set global long_query_time = 3;设置阈值3s的就是慢sql 然后重启
show variables like 'long_query_time %';
可以用select sleep(4) 去模拟查询4s的sql;
可以用mysqldumpslow日志分析工具分析日志。
mysqldumpslow --help
s：表示按照何种方式排序
c:访问次数
I:返回记录
t:查询时间
al:平均锁定时间
ar:平均返回记录数
at:平均查询时间
t:即为返回前面多少条的数据；
g:后边搭配一个正则表达式，大小写不敏感的；
存储过程：
类似于java中的方法
sql: create function
批量数据脚本
show profile 全局查询日志
首先创建函数，假如报错，this function has none of DETEMINISTIC
#犹豫开启过慢查询日志：因为我们开启了bin-log我们就必须为我们的function指定一个参数
show variables like 'log_bin_trust_function_creators';
set global log_bin_trust_function_creators = 1 ;
#这样添加了参数以后，如果mysqld重启，上述参数又会消失
永久方法：window ：my.int[mysqld] 加上log_bin_trust_function_creators = 1
linux下 、/etc/my.cnf下 my.cnf[mysqld] 加上log_bin_trust_function_creators = 1;
语法：
DELIMITER ＄＄
create function rand_string(n int ) returns varchar(255)
BEGIN
DECLARE chars_str varchar(100) DEFAULT ' ';
DECLARE return_str varchar(255) DEFAULT '';
DECLARE i int DEFAULT 0;
while i<100 DO
set return_str = concat(return_str,chars_str,1)
return return_str;
END $$;
调用：DELIMITER ;
CALL 存储过程名称；
show profile 全局查询日志；
是用来分析当前会话中语句执行的资源消耗情况，可以用于mysql的调优的测量
默认情况下参数属于关闭状态，并保存最近15次的运行结果
开启：1.查看当前版本是否支持
2.开启功能，默认是关闭
show variables like 'profiling'; set profiling = on ;
3运行sql
4.查询结果 show profiles;
5.诊断sql show profile cpu,block io for query + sql 前面的数字;
type :all -所有开销
block io 显示块io相关开销
context switches 上下文切换开销
cpu
IPC显示发送和接收相关信息开销
MEMORY 显示内存相关信息开销
PAGE FAULTS 显示页面错误相关开销
SOURCE 显示和source_function ,source_file,source_line相关的开销信息
swaps 显示交换次数相关信息开销的信息
当STATUS 出现如下问题时一定有问题：
convert HEAP to myISAM 查询结果集太大，内存不够用了往磁盘上搬
CREATING tmp table 创建临时表 拷贝数据到临时表用完再删除
copying to tmp table on disk 把内存中临时表复制到磁盘，危险！！！
removing to tmp table
locked
命令：set global general_log = 1
set global log_out_put = 'TABLE'
此后，你所编写的sql将会记录到mysql库里面的general_log表里面
可用 select * from mysql.general_log;
锁机制：协调多个进程或者线程并发访问的某一资源机制
读锁：针对同一份数据，多个读操作之间可以同时进行而互不影响。
写锁：排他锁，当前写操作完成前他会阻断其他写锁和读锁
表锁：偏向MyISAM存储引擎，开销小，加锁快：无死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低
查看表上加过的锁的命令
show open tables ;
手动增加表锁
lock tables 表名 read （write） ,其他；
释放表；
unlock tables;
加完读锁：当前线程可以读当前库，其他线程也可以读当前表
不可以修改当前锁定的库，其他线程无法操作当前锁定的表
不可以访问其他未锁定的库，其他线程可以查询或者更新未锁定的表，其他线程插入或者更新会一直等待，直到锁释放，才可以完成
加完写锁：1.当前线程加完写锁可以对当前表读写，其他线程不行，会阻塞。
总结：MyISAM 在执行查询语句前，会自动给所涉及的表加读锁，在执行增删改操作前，会自动给涉及的表加写锁。
表级锁有两种模式：表共享读锁，表独占写锁
1.加读锁，不会阻塞其他线程对同一表的读请求，但是会阻塞对同一表的写请求，只有当前读锁释放后，才会执行其他进程的写操作
2.对MyISAM进行写操作，会阻塞其他进程对同一表的读和写操作，只有当写锁释放后，才会执行其他进程的读写操作
简而言之，读锁会阻碍写，但是不会阻碍读，写锁读和写都会阻塞。
查看哪些表加锁 ： 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的最大的不同就是支持事务，并且采用了行级锁。
查看当前数据库的事务隔离级别：
show variables like 'tx_isolation'
无索引会导致行锁升级为表锁
间隙锁：当我们使用范围条件而不是相等条件检索数据，并请求共享锁或者排它锁时，INNODB会给符合条件的已有数据记录的索引项加锁，对于键值在条件范围内但是并不存在的记录，叫做间隙、（GAP）
INNODB也会对这个间隙加锁，这种锁机制就是所谓的间隙锁（Next-Key锁）
危害：因为query执行过程中通过范围查找的话，他会锁定范围内的键值，即使这个键值不存在，间隙锁有个比较致命的弱点，当锁定一个范围的键值后，及时某些不存在的键值也会被无辜的锁定，而造成在范围内的值被锁定时无法操作任何数据，在某些情况下可能会对性能造成很大的危害
如何锁定一行： select * from test_innodb_lock where id ='1' for update ;
for update锁定某一行后，其他的操作会被阻塞，知道锁定行的会话提交commit;
行锁的分析：
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:系统从启动后到现在总共的等待的次数
当等待时长比较多，并且等待次数也不少的时候需要分析并进行优化
优化建议：
1.尽可能让所有数据都通过索引去完成，避免无索引行为引发行锁升级为表锁
2.合理设计索引，尽量缩小所得范围
3.尽可能减少检索条件，避免间隙锁
4.尽量控制事务大小，较少资源锁定亮和时间长度
5.尽量降低事务隔离级别
页锁界于表锁和行锁之间，会出现死锁，锁定力度界于表锁和行锁之间，并发度一般。
主从复制：
复制的基本原理：slave 会从binlog来进行数据同步
复制步骤 1.master将改变记录到二进制日志（binary log） 这些记录过程叫做二进制日志文件 binary log events;
2.slave将master 的binary log events 拷贝到它的中继日志（relay log）;
3.slave继续重做中继日志中的事件，将改变应用到自己的数据库中，mysql复制是异步的且串行化的
复制的基本原则：1.每个slave只有一个master
2.每个slave 只有一个唯一的服务器ID
3.每个master可以有多个salve
要求:mysql版本一致且后台以服务运行
同一网段能ping通
主从都配置在mysqld节点下都是小写
主机修改my.ini配置文件丛机修改my.cnf配置文件 然后重启服务
配置 server-id =1 主机唯一id
log-bin=自己本地路径/mysqlbin 必须启用二进制文件
log-err = 自己本地文件路径/mysqllogerr 错误日志（可选）
basedir = "自己本地路径" 根目录（可选）
tmpdir = "本地路径" 临时目录（可选）
datadir = '自己本地路径/Data' 数据目录（可选）
read-only = 0; 读写都可以
binlog-ignore-db=不 需要复制的主数据库名字 [可选]
binlog-do-db= 需要复制的主数据库名字 [可选]
关闭防火墙
service iptables stop;
从机上配置需要复制的主机
在主机上建立 账户并且授权slave
grant replication slave on *.* to 'zhangsan' @'丛机数据库ip' identfied by '123456(密码)'；授权复制
flush privileges ;刷新权限
show master status;查看主机状态
show slave status;
change master to master_host = 'ip地址'，master_user = '张三'，master_password='123456',master_log_file = '',master_log_pos = ;
start slave;启动复制功能
show slave status\G;
显示slave_io_running:yes;
slave_sql_running:yes；则成功
stop slave;停止从服务复制功能
3.服务器调优及各个参数配置（缓存，线程数等）
464
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
