MySQL：

大规模，高并发web服务器体系结构：

Mysql复制（主从复制，组复制），nginx，lnmp，memcached，tomcat（java，serverlet，集群），varnish（web object缓存  squid）

Nosql（redis，mongodb）

Mysql日志类型：

二进制日志：

格式：基于语句statement；基于row行的；混合的（Mix）

默认位置：数据目录

mysql-bin.xxxxx （编号向后转移）

Mysql-bin.index:二进制文件索引文件

查看当前使用的二进制文件是哪一个并且处于哪一个prisation上：

mysql>show master status;

查看二进制文件内容：

Mysql>show BINLOG EVENTS IN “FILES”;

Mysql>show BINARY LOGS；查看当前mysql上所存在的仍然能够使用的二进制文件列表。

滚动：二进制日志达到上限就会滚动；执行flush logs；服务器重启

mysql 里面删除日志文件（不推荐使用rm命令）：

Mysql>PURGE

最大文件大小，

事物日志，错误日志，查询日志，中继日志，慢查询日志

Mysql记录一个事件event：

1，Timestamp：时间戳

2.Position：位置，偏移量，offest

3，事件本身

4，server-id

双主架构中，无法实现写操作。如果同时写互相矛盾的操作就有问题

垂直拆分：一个库分成多个库

水平拆分：拆表（依据不同的标准）

路由：知道你要查询的目标在哪个服务器上，再整合每个查询结果返回给用户

二进制日志（记录MySQL服务器的每一次操作）用来即时点还原：

二进制日志恢复的数据跟原来的数据不是完全一样，  服务器有多个cpu，在处理数据的时候并发交叉进行，而二进制文件只有一个（只有一个来执行写的操作，串行），

事务的隔离级别比较低，在并行恢复的时候仍然会产生影响。

Mysql隔离级别：

READ-UNCOMITTED

READ-COMITTED

REPEATABLE-READ ###默认使用

SERIALIZABLE

如果使用的默认隔离级别，二进制日志格式是statement，就很可能导致二进制文件恢复的数据不一致。

READ-*和mixed时也可能导致数据不一致，建议使用row格式。

二进制日志本身不能替代数据备份，太慢。

Mysql复制 ： 在1上写入数据到数据库，与此同时在二进制文件中保存一份操作，将此文件发送到另一个服务器2上，2在收到这个文件的时候先保存的本地日志relay log（中继日志）中，然后在MySQL里面执行，执行之后保存到数据库中。中继日志除了中继从服务器的日志外没有任何其他作用。

Mysql允许多级复制：从服务器也可以拥有自己的从服务器，此时，主服务器的从服务器就可以使用自己的二进制文件来进行从自己到从服务器的主从复制。如果从服务器过多的话可以采用多级复制，避免了因为复制使用过多的线程，减轻主服务器的复制线程。如果中间的服务器不需要保存数据，可以将数据库引擎设置为black hole （/dev/null）该创建创建，该写就写，写完之后就丢弃，不保存。

复制的作用：

辅助实现备份

  高可用

异地容灾

分担负载scale  out；

Mysql引擎：innodb ；mylASM ；black hole

Mysql读写分离： mysql-proxy   amoeba cobar（业务逻辑拆分工具，数据拆分）

通过mysql代理来实现，当客户端访问的sql语句是读语句的时候分配到从服务器上，当是写语句的时候分配到主服务器上。

异步  半同步  同步 ：

Mysql主从复制（可以一主多从）默认是异步

MySQL5.5以后支持半同步：在一主多从中，只要有一个从服务器返回执行的消息，master就认为是所有从服务器复制完成。

针对数据库的不同设置从服务器的写权限

冷备份

Drbd中的半同步：数据只要发送到tcp/ip的缓存中就好了

一个salve只能有一个master

Mysql 5.5 之前复制

5.6gtid全局事务号，在多事务执行的时候不会产生事务混乱，引入multi-thread replication 多线程复制

主服务器端自动启动dump线程，从服务器启动I/O线程，主动去查看主服务器的二进制文件是否有改动，如果有，主服务器就会启动dump线程复制bin-log文件到从服务器I/O线程，从服务器再开启sql线程，读取中继日志进行本地执行回放

SSL双向验证

Mysql主从复制过滤：结合通配符% __

主master：

Binlog-do-db:仅将指定数据库的相关修改操作记入二进制日志

Bin-ignore-db

从slave：

Replicate-do-db

Replicate-ignore-db

Replicate-do-table

Replicate-ingore-table

Replicate-wild-do-table

Replicate-wild-ingore-table

Mysql5.6：

1.Gtid :标识每一个主机上的事务的id，追踪比较事务  innodb高可用依靠gtid来实现

2.多线程复制：每个数据库只能使用一个线程。多个数据库时使用多线程复制

并发线程工作数Slave-parallel-workers=n ##0 禁用多线程功能

Mysqlreplication

Mysqlrplcheck

Mysql优化：

1，sql语句优化

2，索引优化

3，数据库结构优化

4，innodb表优化

5，myiasm表优化

6，memroy表优化

7，理解查询执行计划

8，缓冲和缓存 缓存常用的表，缓冲数据

9，锁优化 只能有一个操作--》用不同级别的锁（表锁，页锁，行锁）

10，MySQL服务器优化

11，性能评估

12，mysql优化内幕

MySQL优化需要在三个不同层次协调进行：

MySQL级别，OS级别和硬件级别

1，MySQL级别的优化包括表优化，查询优化和MySQL服务器配置优化。MySQL的各种数据结构有最终作用于OS直至硬件设备，因此还需要了解每种结构OS级别的资源的需要并最终导致的cpu和I/O操作，并在此基础上将CPU及I/O操作需要尽量降低以提升其效率。

2，数据库层面的优化着眼点：

1）是否正确设置了表结构的相关属性，尤其是每个字段的字段类型是否为最佳，是否为特定类型的工作设置了合适的表及表字段。

2）是否为高效查询创建了合适的索引。

3）是否为每张表设置了合适的村成功与引擎，并且有效利用了存储引擎本身的优势和特征。

4）是否基于存储引擎为表选用了合适的行格式。

5）是否使用了合适的锁策略

6）是否为innodb的缓冲池，myiasm的键缓存以及MySQL查询缓存设定了合适大小的内存空间，以便存储频繁访问的数据切不会引起页面换出。

操作系统和硬件级别的优化：

1）是否为实际工作选用了合适的cpu

2）是否有着合适的大小的物理内存，并通过合理的配置平衡内存和磁盘资源

3）是否选用了合适的网络设备并正确地配置了网络对整体系统也有着重大影响。延迟和带宽是网络延迟的限制因素。常见问题有丢包。

4）是否基于操作系统选择了合适的文件系统

5）MySQL是否对线程进行了有效的管理。

Mylasm引擎：数据挖掘，性能较优

.MYD数据

.MYI索引

.frm表结构

Innodb引擎：在线事务

.frm表结构

.ibd: 表空间

数据

索引

MySQL