在5.6以后，可以通过命令动态修改.

注意有些命令是需要主从都要执行，有些命令是只在slave执行。

gtid_mode 的几种状态值说明：
OFF: 不产生 GTID, 基于 binlog+position,也不能接受GTID的日志。默认值
OFF_PERMISSIVE:  不生产 GTID,但作为slave可以识别GTID事务也可以识别非GTID事务
ON_PERMISSIVE: 产生GTID，slave可以处理GTID事务和非GTID事务
ON: 产生GTID事务，slave只接受GTID事务

实验一：将传统复制切换到GTID复制

启用GTID:

set @@global.enforce_gtid_consitency=warn;
set @@global.enforce_gtid_consistency=on;
set @@global.gtid_mode=OFF_PERMISSIVE; #不产生gtid,但可以处理gtid
set @@global.gtid_mode=ON_PERMISSIVE; #产生gtid,也可以处理gtid
show status like ‘ONGOING_ANONYMOUS_TRANSACTION_COUNT’;
set @@global.gtid_ode=on;

stop slave [for channel ‘channel’];change master to master_auto_postion=1; start slave;（slave)

更改复制到自动识别GTID环境 Continue reading →

在5.7下半同步是以插件的形式出现的，所以在启用半同步前要先安装半同步插件 semisync_master.so

On the master:

INSTALL PLUGIN rpl_remi_sync_master SONAME 'semisync_master.so';

On slave slave:

INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';

在my.cnf里配置,要写在mysqld段

master:

[mysqld]
repl_semi_sync_master_enable=1
repl_semi_sync_master_timeout=1000 #1 second

slave:

[mysqld]
repl_semi_sync_slave_enable=1

卸载插件：

uninstall plugin rpl_semi_sync_master; # master
uninstall plugin rpl_semi_sync_slave;  # slave

在主上设置slave的数量，用来接受slave返回的次数数量2,用来分析 show global variables like ‘%semi%’;

set global rpl_semi_sync_master_wait_for_slave_count=2;

监控：

show global status like 'rpl_semi_sync%';

架构为两主一从，两主为同一台服务器的多实例，安装方法请参考上篇文章http://blog.haohtml.com/archives/17300。

主master1    IP: 192.168.1.116     PORT: 3306
主master2    IP: 192.168.1.116     PORT: 3307
从slave        IP: 192.168.1.200     PORT: 3306

两主为全新安装。如果以前安装过的话，可以将原来的数据库删除掉，再执行 reset master即可。(否则需要将两个主的想着库表使用 mysqldump到从中)

[master1 3306] my.cnf
[client]
port=3306
socket=/data/mysql/mysql3306/tmp/mysql.sock

[mysqld]
basedir=/data/mysql/mysql3306
datadir=/data/mysql/mysql3306/datadir
#socket=/var/lib/mysql/mysql.sock
socket=/data/mysql/mysql3306/tmp/mysql.sock
port=3306

log-bin=mysql-bin
binlog-format=row

# 二进制日志的格式：有row、statement和mixed三种   Continue reading →

http://www.cnblogs.com/gomysql/p/3650645.html

1. 一个存放记录(row)的page，由page header、page trailer、page body组成。如下图:^[2]
   
   

Continue reading →

这两个名字虽然都叫做索引，但这并不是一种单独的索引类型，而是一种数据存储方式。对于聚簇索引存储来说，行数据和主键B+树存储在一起，辅助键B+树只存储辅助键和主键，主键和非主键B+树几乎是两种类型的树。对于非聚簇索引存储来说，主键B+树在叶子节点存储指向真正数据行的指针，而非主键。

InnoDB使用的是聚簇索引，将主键组织到一棵B+树中，而行数据就储存在叶子节点上，若使用”where id = 14″这样的条件查找主键，则按照B+树的检索算法即可查找到对应的叶节点，之后获得行数据。若对Name列进行条件搜索，则需要两个步骤：第一步在辅助索引B+树中检索Name，到达其叶子节点获取对应的主键。第二步使用主键在主索引B+树种再执行一次B+树检索操作，最终到达叶子节点即可获取整行数据。

MyISM使用的是非聚簇索引，非聚簇索引的两棵B+树看上去没什么不同，节点的结构完全一致只是存储的内容不同而已，主键索引B+树的节点存储了主键，辅助键索引B+树存储了辅助键。表数据存储在独立的地方，这两颗B+树的叶子节点都使用一个地址指向真正的表数据，对于表数据来说，这两个键没有任何差别。由于索引树是独立的，通过辅助键检索无需访问主键的索引树。

MyISAM索引用的B+ tree来储存数据，MyISAM表的索引和数据是分开的，MyISAM索引的指针指向的是键值的地址(0XX开始之类的物理地址)，地址存储的是数据，如下图：

为了更形象说明这两种索引的区别，我们假想一个表如下图存储了4行数据。其中Id作为主索引，Name作为辅助索引。图示清晰的显示了聚簇索引和非聚簇索引的差异。

x

我们重点关注聚簇索引，看上去聚簇索引的效率明显要低于非聚簇索引，因为每次使用辅助索引检索都要经过两次B+树查找，这不是多此一举吗？聚簇索引的优势在哪？

1 由于行数据和叶子节点存储在一起，这样主键和行数据是一起被载入内存的，找到叶子节点就可以立刻将行数据返回了，如果按照主键Id来组织数据，获得数据更快。

2 辅助索引使用主键作为”指针” 而不是使用地址值作为指针的好处是，减少了当出现行移动或者数据页分裂时辅助索引的维护工作，使用主键值当作指针会让辅助索引占用更多的空间，换来的好处是InnoDB在移动行时无须更新辅助索引中的这个”指针”。也就是说行的位置（实现中通过16K的Page来定位，后面会涉及）会随着数据库里数据的修改而发生变化（前面的B+树节点分裂以及Page的分裂），使用聚簇索引就可以保证不管这个主键B+树的节点如何变化，辅助索引树都不受影响。

参考：http://www.tuicool.com/articles/ZRN3qu

转：http://www.cnblogs.com/shijingxiang/articles/4743324.html

http://fireflyclub.org/?/article/37

http://www.cnblogs.com/yuyue2014/p/4738007.html

注意这篇文章并非死锁的，而是锁等待

如果遇到死锁了，怎么解决呢？找到原始的锁ID，然后KILL掉一直持有的那个线程就可以了， 但是众多线程，可怎么找到引起死锁的线程ID呢？ MySQL 发展到现在，已经非常强大了，这个问题很好解决。 直接从数据字典连查找。

Continue reading →

如上所示，mysql中关于read的计数器，有7个。他们的数值对于系统的状况的了解，对于系统的调优都十分重要。我们应该理解他们的含义。本文是自己的一些理解。
首先7个计数器，我们应该分为两部分：
1）对索引读的计数器：前面的5个都是对索引读情况的计数器，
Handler_read_first：是指读索引的第一项（的次数）；
Handler_read_key：是指读索引的某一项（的次数）；
Handler_read_next：是指读索引的下一项（的次数）；
Handler_read_last：是指读索引的最后第一项（的次数）；
Handler_read_prev：是指读索引的前一项（的次数）；
5者应该有四种组合：
1. Handler_read_first 和 Handler_read_next 组合应该是索引覆盖扫描
2. Handler_read_key 基于索引取值
3. Handler_read_key 和 Handler_read_next 组合应该是索引范围扫描
4. Handler_read_last 和 Handler_read_prev 组合应该是索引范围扫描（orde by desc）

2）对数据文件的计数器：后面的2个都是对数据文件读情况的计数器，
Handler_read_rnd:
The number of requests to read a row based on a fixed position. This value is high if you are doing a lot of queries that require sorting of the result. You probably have a lot of queries that require MySQL to scan entire tables or you have joins that do not use keys properly.

Handler_read_rnd_next

The number of requests to read the next row in the data file. This value is high if you are doing a lot of
table scans. Generally this suggests that your tables are not properly indexed or that your queries are
not written to take advantage of the indexes you have.

这里很重要的一点要理解：索引项之间都是有顺序的，所以才有first, last, next, prev等等，所以前面的5个都是对索引读情况
的计数器，而后面的2个是对数据文件的读情况的计数器。

很显然的一点：
后面的2个 Handler_read_rnd 和 Handler_read_rnd_next 是越低越好，如果很高，应该进行索引相关的调优。而Handler_read_key的数值
肯定是越高越好，越高代表使用索引读很高。其他的计数器，要具体情况具体分析

http://blog.chinaunix.net/uid-25909722-id-4378355.html