MySQL数据库性能优化史诗级大总结

+ 未提交读
+ 已提交读（Mysql不是默认，SQLServer和Oracle是默认）
+ 可重复读（InnoDB默认）
+ 可串行化

- 存储容量
- 传输速度
- 访问时间
- 主轴转速
- 物理尺寸

RAID0 是最早出现的模式，成为数据条带，是最简单的一种方式，只需要2块以上的硬盘即可，成本较低，可以提高整个磁盘的性能的吞吐量。RAID没有提供荣誉或者错误修复能力，但是实现成本较高。容量是所有磁盘的总和，并且性能是之前的N倍。
RAID1 是磁盘镜像，原理就是把一个数据镜像到另一个磁盘上，最大限度的保证系统的可靠性和可修复性。
RAID5 是分布式奇偶校验磁盘阵列，主要就是把数据分散到多个磁盘上，如果任何一个磁盘损坏都可以快速重建，但是如果2块失效就全部无法恢复。最好使用在以读取为主要任务的服务器上，比如从数据库服务器。
RAID10 分片的磁盘镜像，对磁盘先进行RAID1，然后对两组RAID1进行RAID0，对读写都有较好的性能，重建速度快于RAID5。

内核相关参数：/etc/sysctl.conf
net.core.somaxconn=65535
net.core.netdev_max_backlog=65535
net.ipv4.tcp_max_syn_backlog=65535
net.ipv4.tcp_fin_timeout=10
net.ipv4.tcp_tw_reuse=1
net.ipv4.tcp_tw_recycle=1
net.core.wmem_default=87380
net.core.wmem_max=16777216
net.core.rmem_default=87380
net.core.rmem_max=16777216
net.ipv4.tcp_keepalive_time=120
net.ipv4.tcp_keepalive_intvl=30
net.ipv4.tcp_keepalive_probes=3
kernel.shmmax=4294967295    # 用于定义单个共享内存段的最大值, 
                            # 这个参数应该设置的足够大, 以便能在一个共享内存段中容纳下整个InnoDB缓冲池
                            # 对于x64的系统, 可取的最大值为物理内存的大小减去1字节，建议值为大于物理内存的一半
vm.swappiness=0             # 该参数当内存不足时对性能产生比较明显的影响, 设置内存交换区大小
                            # 0表示除非Linux内核非虚拟内存完全满了, 否则就不使用交换区
资源限制：/etc/security/limit.conf
该文件是Linux PAM，也就是插入式认证模块的配置文件, 打开文件数的限制。
* soft nofile 65535
* hard nofile 65535

参数：
* 表示对所有用户有效
soft 表示当前系统生效的设置
hard 表示系统中所能设置的最大值
nofile 表示所限制的资源是打开文件的最大数目
65535 表示限制的数量

磁盘调度策略：/sys/block/devname/queue/scheduler
默认是使用cfq策略
noop（电梯式调度策略）, 实现了一个FIFO队列, 像电梯一样对IO请求进行组织, 当有一个新的请求到来时, 将会合并到最近的请求之后
以此来保证同一请求同一个介质。noop倾向饿死读而利于写, 一次noop对于闪存设备,RAM,嵌入式系统是最好的选择。
deadline（截止时间调度策略）确保在一个时间内服务请求, 这个截止时间是可以调整的, 而默认读期限短于写期限。
这样就会防止写操作因为不能被读取而饿死的现象, deadline对数据库类应用是最好的选择。
anticipatory（预料IO调度策略）本质上与deadline一样, 但是最后一个读操作后要等待6毫秒才能继续进行其他的IO请求进行调度。
写入流合并成为一个大的写入流, 用写入延时换区最大的写入吞吐量, 这种策略适合于写入较多的环境，比如文件服务器，该策略对数据环境表现较差

配置文件：/etc/fstab
data=writeback|ordered|journal
wirteback对于InnoDB引擎来说是最好的
noatime和nodiratime用来禁止记录时间

并发性与锁级别：使用表级锁，读取表中数据时也需要全表加共享锁。
表损坏修复：支持对于任意关闭和其他情况导致的损坏修复，对MyISAM表进行数据恢复可能造成数据丢失，因为不支持事务。
使用 check table 表名称 来检查，使用 repair table 表名 来进行恢复。
支持全文索引，支持数据压缩，适用于只读操作的数据表，可以通过myisampack -b -f xxx.MYI进行压缩。
对于已经压缩的表只能读取。

在Mysql5.0之前的版本中默认表大小为最大4GB。
存储大表则需要修改MAX_Rows和AVG_ROW_LENGTH参数。
在Mysql5.0以后，默认表大小支持256TB。
使用场景：
适用于非事务应用
适用于只读类应用
适用于空间类应用

具体参数配置在innodb_file_per_file。
参数值为on的时候：表空间为TableName.ibd。
参数值为off的时候：表空间存储在共享表空间：ibdataN,N表示一个数字。

在Mysql5.5版本之前的innodb_file_per_file默认是off。
在一个繁忙的系统中，系统表空间会增大，但是删除一部分无用的数据时系统表空间并没有缩小，要通过复制数据来解决，也就是说系统表空间无法简单的收缩文件。
系统表空间由于只有一个文件，多余多个表同时操作来说，系统表空间会产生IO瓶颈。
独立表空间可以同时向多个文件刷新数据。
在Mysql5.6之后，默认使用独立表空间进行管理，建议使用独立表空间。

使用mysqldump导出所有数据, 存储过程/触发器/视图也要导出。
使用停止Mysql服务，修改参数，删除InnoDB相关文件。
重启Mysql服务，重建InnoDB系统表空间。
重新导入数据。

主要针对管理共享资源的并发访问而设计。
实现事务的隔离性。
分为共享锁（读锁）和独占锁（写锁）。
阻塞：一个锁需要等待另一个锁的释放就会导致阻塞。
死锁：两个锁及以上相互等待对方释放锁。

以文件方式存储
csv文件存储表内容
csm文件存储元数据和数据量
frm文件存储表结构
CSV所有列不允许为NULL
不支持索引，不适合大表和OLTP
可以直接编辑
适用于作为数据交换的中间表

支持插入和查询操作
只允许在自增ID列上加索引
以zlib对数据表进行压缩，磁盘IO更少
数据存储在arz文件中
支持行级锁和标准的缓冲区，支持高并发插入
适用于日志和数据采集类的应用

也称之为Heap存储引擎，所以数据保存在内存中。
只有一个表结构frm文件。
支持Hash索引（默认，适用于等值查找）和BTree索引（适用于范围查找）。
所有字段都为定长。
不支持Blob和Text等大字段类型。
使用表级锁。
数据表的最大大小由max_heap_table_size参数决定， 对于已经存在的数据表是不生效的。
Memory存储引擎表和临时表的区别是临时表对于当前会话是可见的，而Memory临时表对于所有会话可见。
系统使用临时表如果没有超过限制将会使用Memory表否则使用MyISAM引擎的数据表。
会话临时表使用create temporary table来创建。
用于查找或者是映射表。
用于保存数据分析产生的中间数据。
用于缓存周期性聚合数据的结果表。

提供远程访问其他Mysql服务器上数据表的方法。
本地不保存数据，数据全部存放到远程服务器上。
本地需要保存远程表结构和远程服务器连接信息。
默认是禁止的，启动时需要指定参数federated
适用于偶尔的数据查询中
engine=federated connection='mysql://UserName[:PassWord]@HostName[:PortName]/DBName/TableName';
查看是否支持该存储引擎：

命令行参数：mysqld_safe --datadir=/data/sql_data。
配置文件， 查看配置文件读取顺序及位置：
mysqld --help --verbose | grep -A 1 'Default options' /etc/my.cnf

全局参数：set global 参数名=参数值;和set @@global.参数名 := 参数值;
会话参数：set [session] 参数名=参数值;和set @@session.参数名=参数值;

确定可以使用的内存上限。
确定Mysql的每个连接使用的内存。
sort_buffer_size设置排序需要的内存。
join_buffer_size设置连接缓冲区的内存。
read_buffer_size设置全表扫描时需要的内存大小。
read_rnd_buffer_size设置索引缓冲区的大小。
如何为缓存池分配内存：
    innodb_buffer_pool_size定义了InnoDB缓存池的大小。
    总内存-(每个线程所需要的内存 x 连接数)-系统保留内存
    key_buffer_size是为MyISAM缓存池设置大小的，该引擎只会缓存索引，数据还会依赖于操作系统的缓存
    通过下面的查询来确定MyISAM所占用的空间大小：select sum(index_length) from information_schema.tables where engine='myisam';

innodb_log_file_size控制事务日志的大小。
innodb_log_files_in_groups控制事务日志的个数。
事务日志的总大小=innodb_log_file_size x innodb_log_files_in_groups。
innodb_log_buffer_size控制日志缓存区的大小。
innodb_flush_log_at_trx_commit控制刷新日志缓冲区的频率：
      0表示每秒进行一次log写入cache，并flush log到磁盘。
      1默认，表示在每次事务提交执行log写入cache，并flush log到磁盘。
      2建议使用该值，每次事务提交执行log数据写入到cache，每秒执行一次flush log磁盘。
innodb_flush_method=O_DIRECT,对于Linux系统建议使用该选项，避免操作系统和InnoDB都对数据进行缓存。
innodb_file_per_table=1, 控制InnoDB的表空间。
innodb_doublewrite=1, 控制是否使用双写缓存，启用后稍微影响性能，但是安全性提高。

delay_key_write：
off表示每次写操作后刷新键缓冲中的脏块到磁盘。
on表示只对键表时指定了delay_key_write选项的表使用延迟刷新。
all表示对所有MyISAM表都是用延迟键写入。

expire_logs_days指定自动清理binlog的天数。
max_allowed_packet控制Mysql可以接受的包大小。
skip_name_resolve禁用DNS查找。
sysdate_is_now确保sysdate()函数返回确定性日期。
read_only禁止非super权限的用户写入权限。
skip_slave_start禁用slave自动恢复。
sql_mode设置Mysql所使用的SQL模式，默认很宽松的:
        strict_trans_tables
        no_engine_subtitution
        no_size_date
        no_zero_in_date
        only_full_group_by

其他常用参数
    sync_binlog控制Mysql如何向磁盘刷新binlog，默认使用操作系统刷新策略。
    tmp_table_size和max_heap_table_size控制内存临时表大小。
    max_connections控制允许的最大连接数, 通常设置为2000。

数据库的结构和SQL优化（影响最大）

    过分的反范式化为表建立太多的列。
    过分的范式化造成太多关联的表, 一般建议不超过10个关联表。
    在OLTP环境中使用不恰当的分区表。
    使用外键保证数据完整性。

总体优化步骤：

    数据库表结构设计和SQL语句
    数据库存储引擎和参数配置的优化
    系统优化
    硬件升级

--auto-generate-sql,由系统自动生成SQL脚本进行测试。
--auto-generate-sql-add-autoincrement在生成的表中增加自增ID。
--auto-generate-sql-load-type指定测试找那个使用的查询类型。
--auto-generate-sql-write-number指定初始化数据时生成的数据量。
--concurrency指定并发线程的数量，逗号分隔多个并发。
--engine指定测试表的存储引擎，逗号分隔多个引擎。
--no-drop指定不清理测试数据。
--iterations指定测试运行的次数。
--number-of-queries指定每一个线程的查询数量。
--debug-info指定输出额外的内存及CPU统计信息。
--number-int-cols指定测试表中INT类型列的数量。
--number-char-cols指定测试表中CHAR类型列的数量。
--create-schema指定用于执行测试的数据库的名字。
--query用于自定义SQL的脚本。
only-print并不运行测试脚本，而是把生成的脚本打印出来。

安装：

使用wget进行下载
使用unzip进行解压
进入解压目录
运行./autogen.sh脚本
运行./configure --with-mysql-includes=/usr/local/mysql/include --with-mysql-libs=/usr/local/mysql/lib
编译安装make && make install
常用参数：

--test用于指定所要执行的测试类型：
fileio 用于文件系统的IO性能测试
cpu CPU性能测试
memory 内存性能测试
--mysql-db用于指定基准测试的数据库名。
--mysql-table-engine用于指定所使用的存储引擎。
--oltp-tables-count执行测试的表的数量。
--oltp-table-size指定每个表中的数据行数。
--num-threads指定测试的并发线程数量。
--max-time指定最大测试时间。
--report-interval指定间隔多长时间输出一次统计信息。
--mysql-user指定执行测试的Mysql用户。
--mysql-password指定执行测试的Mysql用户的密码。
prepare用于准备测试数据。
run用于实际进行测试。
cleanup用于清理测试数据。

尽量减少数据冗余。
尽量避免数据维护中出现的更新插入和删除异常。
    插入异常：如果表中的某个实体随着另一个实体而存在就会产生插入异常。
    更新异常：如果更新某个表中的某个实体的单独属性时，需要对多行进行更新。
    删除异常：如果删除某个表中的实体，也会导致其他实体被删除。
节约数据存储空间
提高查询的效率

需求分析：全面了解产品设计的存储需求
存储需求。
数据处理需求。
数据安全性和完整性。
逻辑设计：设计数据的逻辑存储结构
数据实体之家的逻辑关系，解决数据冗余和数据维护异常。
物理设计：
根据所使用的数据库特点进行表结构设计
维护优化：
根据实际情况对索引、存储结构等进行优化

可读性原则
表意性原则
长名原则（尽量避免过多使用缩写）
选择合适的存储引擎

利用二进制日志增量进行
不需要太多的带宽
但是使用基于行的复制在进行大批量的更改时会对带宽带来一定压力
特别是在跨IDC环境下进行复制
应该分批复制

需要其他组件配合完成
利用DNS轮询的方式把程序的读连接到不同的备份数据库
使用LVS、HAProxy等代理方式

利用备库的备份来减少主库的负载
复制并不能替代备份

1. Mysql服务层日志

二进制日志
慢查询日志
通用日志

2. Mysql存储引擎层日志

InnoDB的重做日志
InnoDB的回滚日志
二进制日志记录了对Mysql数据库的修改事件，包括增删改查事件和表结构修改事件。

在binlog中记录的日志都是成功执行过的日志。

3. 二进制日志的记录格式

无论使用哪一种日志格式，进行DDL操作时都是使用基于段的日志格式。

如果同一条SQL对N条数据进行修改，基于段的日志之后记录1条，基于行的会记录N条。

SBR 基于段的格式binlog_format=SATEMENT（Mysql5.7之前默认使用的格式）

优点：
日志量相对较小，节约磁盘网络IO。
并不强制要求主从数据库的表定义的完全相同。
相对于基于行的复制更加灵活。
缺点：
非确定性事件、存储过程、触发器、自定义函数、UUID()或user()等函数可能造成Mysql复制的主备服务器数据不一致。
需要更多地锁。

RBR 基于行的日志格式binlog_format=ROW
优点：
使Mysql主从复制更加安全，在备用服务器上复制效率高，可以通过反向处理方式恢复某些数据。
可以应用于任何SQL的复制。可以减少从服务器上锁的使用。
缺点：
记录日志量大。binlog_row_image=[FULL|MINIMAL|NOBLOB]
要求主从数据库服务器的表结构一致，否则可能造成中断复制。
无法在从服务器上单独执行触发器，因为直接应用了SQL执行后的修改。

SBR+RBR 混合日志格式binlog_format=MINED
根据SQL语句由系统决定基于段和基于行的日志格式进行选择
数据量大小根据所执行的SQL语句决定
建议选择混合日志格式，如果选择为ROW格式，建议设置binlog_row_image=MINIMAL

在从服务器启动一个IO工作线程。
IO工作线程与主库建立普通的连接。
在主数据库服务器上启动特殊的二进制日志转储线程，成为binlog_dump线程。
然后从服务器读取主服务器上的事件，当从服务器追赶上主服务器的时候从服务器会进入sleep状态。

在主数据库服务器建立复制账号：create user 'repl'@'IP地址段' identified by '密码';。
授权用户：grant replication slave on *.* to 'repl'@'IP地址段';。
主服务器配置BinLog：bin_log=存储目录。
主服务器配置ID：server_id=100。
从服务器配置BinLog：bin_log=存储目录。
从服务器配置ID：server_id=101。
从服务器配置RelayLog：relay_log=存储目录。
从服务器配置LogSlaveUpdate:log_slave_update=on可选。
从服务器配置ReadOnly:read_only=on可选。
常用的工具：mysqldump、xtrabackup。
从服务器启动复制链路：change master to master_host='主服务器IP地址', master_password='主服务器密码', master_log_file='主服务器日志文件名称', master_log_pos=偏移量;。
主服务器日志文件名称和偏移量在主服务器中导出的sql文件中可以获得。

从服务器首先会告诉主服务器从服务器已经执行的事务的GTID值。
主服务器返回给从服务器没有执行的GTID值。
同一个事务只在指定的从库执行一次。
主服务器配置BinLog：bin_log=存储目录。
主服务器配置ID：server_id=100。
主服务器配置GTID：gtid_mode=on。
主服务器配置：enforce-gtid-console和log-slave-updates=on。
从服务器配置ID：server_id=101。
从服务器配置RelayLog：relay_log=存储目录。
从服务器配置:gtid_mode=on和enforce-gtid-consistency。
从服务器配置:log-slave-updates=on建议。
从服务器配置:read_only=on建议。
从服务器配置:master_info_repository=表名建议。
从服务器配置:relay_log_info_repository=表名建议。
常用的工具：mysqldump、xtrabackup。
从服务器启动复制链路：change master to master_host='主服务器IP地址', master_password='主服务器密码' , master_auto_position=偏移量;。

基于SQL段的日志是在从数据库上重新执行SQL
基于行的日志是在从数据库上直接应用修改

是Mysql最早使用的复制技术，Bug相对较少
对SQL查询没有任何限制
故障处理比较容易
故障转移时重新获取新主服务器日志点信息比较困难

可以很方便的进行故障转移
从库不会丢失库上的任何修改
故障处理复杂
对执行的SQL有一定限制

所使用的Mysql版本，Mysql5.6+以上可以使用GTID。
复制架构以及主从切换的方式。
所使用的高可用管理组件。
应用的支持程度。

特点：
配置简单。
可以用多个从库分担读负载。
用途：
为不同业务使用不同的从库。
将一台从库放到远程IDC中，用于灾备恢复。
分担主库的读负载。

主主方式注意事项：

两台同时提供服务
两个主中所操作的表最好能够分开
配置一下两个参数:auto_increment_increment=2 // 控制自增列ID步长和auto_increment_offest=1|2 // 控制自增列ID起始数值，一台为1，一台为2
主备方式注意事项：

只有一台服务器对外服务
一台处于只读或者是热备状态
确保两台服务器上的初始数据相同
确保两台服务器上已经启动binlog并且有不同的server_id。
在两台服务器上启用log_slave_updates参数。
初始化的备库上启用read_only参数。

在主从数据库之间建立分发主库，主数据库数据同步到分发主库，分发主库向多个从库分发。

stop slave;
set global slave_parallel_type='logical_clock';
set global slave_parallel_workers=4;
start slave;

由于数据损坏或丢失所引起的主从复制错误
    主库或从库以外宕机引起的错误
    使用跳过二进制日志事件
    注入空事务的方式先恢复中断的复制链路
    使用其他方法来对比主从服务器上的数据
主库上的二进制日志文件损坏
    通过change master命令来重新指定
    检查修复数据
从库上中继日志损坏
在从库上进行了数据修改
不唯一的server_id和server_uuid, 比如多个从库使用相同的server_uuid问题
max_allow_packet设置引起的主从复制错误

磁盘耗尽
性能低的SQL
表结构和索引没有优化
主从数据不一致
人为操作失误

建立完善的监控报警系统
对备份数据进行恢复测试
正确配置数据库环境
对不需要的数据进行归档和清理

解决系统的单点故障
利用SUN共享存储解决
DRDB（以Linux内核模式块级别的同步复制技术）磁盘复制解决
使用多写集群，目前主要是Percona公司提供的PXC集群，所有事务提交以后才算提交完成，取决于性能最差的服务器
使用NDB集群，所有节点都进行主主复制，可以在任何节点进行写入。目前NDB集群的数据都要求存储在内存中。
利用Mysql主从复制来解决，可以使用第三方的复制管理组件
    主库切换以后如何通知应用新的主库的IP地址
    如何检查Mysql主库是否可用
    如何处理从库和新的主库之间的复制关系

主要作用就是监控和管理Mysql主主复制拓扑，并在当前的主服务器失效时，进行主和主备库之间的主从切换和故障转移。
特点：
MMM中同一时间只有一个主库是对外服务的。
MMM可以监控Mysql主从复制健康情况。
在主库出现宕机时进行故障转移并自动配置其他从库对新主库的复制。
MMM提供了主写虚拟IP，在主库出现问题时可以自动迁移虚拟IP。

配置主主复制以及主从同步集群
安装主从节点所需要的支持包
安装及配置MMM工具集
运行MMM监控服务
测试

[优点]使用Perl语言开发，完全开源
[优点]提供了读写VIP，是服务器角色变更时对前端应用透明
[优点]MMM提供了从库延迟监控
[优点]提供了主库故障转移后服务器对新库的重新同步功能
[优点]同时监控多个从库
[缺点]发布时间早导致Mysql新的复制功能支持不够
[缺点]MMM对于Mysql5.6+的多线程同步不支持
[缺点]对于写负载较大的情况下可能会出现读VIP全部迁移到主服务器上
[缺点]没有读负载均衡
[缺点]在主从切换时，容易造成数据丢失
[缺点]MMM监控服务存在单点故障

MHA基本上可以在30s之内完成主从切换，最大程度的保证数据一致性。
只能监控主库是否可用。
当主库不可用时，可以在多个从库中选出新的主库。
提供主从切换和故障转移，尝试在故障机器保存二进制日志。

主从切换的过程：
应用从原生DB服务器上保存的二进制日志。
提升备选主DB服务器为新的主DB服务器。
迁移集群中其他的从DB作为新的主DB的从服务器。

部署步骤：
配置集群内所有主机的SSH免认证登录。
配置主从复制集群(推荐基于GTID的复制)。
配置HMA管理节点。
对配置进行检验。

特点：
[优点]同样适用Perl语言开发的开源工具, 也提供其他语言的接口。
[优点]可以支持基于GTID的复制模式。
[优点]在故障转移时更不易产生数据丢失。
[优点]同一个监控节点可以监控多个集群。
[缺点]没有VIP的实现，需要自己开发相关脚本。
[缺点]需要基于SSH免密登录，存在安全隐患。
[缺点]没有提供多个从库的负载均衡的功能。

为什么要进行读写分离？因为写操作只能在主库上进行，而读操作可以迁移到从库。

方式：

由开发人员控制：直接控制什么样的查询在从库进行，因此比较灵活，由于程序直接连接数据库，因此性能损耗低。但是也加大了工作量。人为控制可能出错较多。
中间件实现：比如mysql-proxy(高并发情况下可能会崩溃)或maxScale(由MariaDB公司提供)。中间件可以根据SQL的语法分析出世读操作还是写操作来实现负载均衡，但是存储过程等并不能分析出来。使用中间件对程序是透明的，程序不需要进行调整。数据库查询处理能力依赖于中间件。对延迟敏感业务无法自动在主库中执行。
读写分离实现了，那么下一步就是读负载均衡了。

负载均衡在软件上可以使用LVS、HAProxy、MaxScale，硬件可以使用F5。

使用B+树存储数据
B+树索引能够加快数据的查询的速度
更加适合进行范围查找

什么情况下用到BTree索引:
全值匹配的查询
匹配最左前缀的查询
匹配列前缀查询
范围查找
精确匹配左前列并范围匹配另外一列
只访问索引的查询

如果不是按照索引最左列开始查找，那么无法使用索引。
使用索引时不能跳过索引中的列。
not in、<>、!=操作无法使用索引。
如果查询中有某个列的范围查询，则其右边的所有列都无法使用索引。

Hash索引是基于Hash表实现的，只有查询条件精确匹配Hash索引中的列时才能够使用Hash索引。
对于Hash索引中的所有列，存储引擎都会为每一行计算一个Hash码，Hash索引中存储的就是Hash码。

在Mysql配置参数中指定slow_query_log。启动停止记录慢查询日志。
在Mysql配置参数中指定slow_query_log_file。指定慢查询日志记录存储路径及文件。
在Mysql配置参数中指定long_query_time。指定记录慢查询日志SQL执行时间的阈值。默认值为10秒。通常改为0.0001秒比较合适。
在Mysql配置参数中指定log_queries_not_using_indexs。是否记录未使用索引的SQL。
使用慢日志查询分析工具mysqldumpslow。
使用慢日志查询分析工具pt-query-digest。

query_cache_type指定查询缓存是否可用。在一个比较繁忙的系统中建议关闭查询缓存。
query_cache_size指定查询缓存的内存大小。
query_cache_limit指定查询缓存可用存储的最大值。
query_cache_wlock_invalidate指定数据表被锁定以后是否返回缓存中的数据。
query_cache_min_res_init指定查询缓存分配的内存块最小单位。

统计信息的不准确
执行计划的成功估算并不等于实际的执行计划的成本，因为Mysql并不知道哪些页面在磁盘上，哪些页面在内存上，哪些需要顺序读取，哪些需要随机读取。
Mysql查询优化器所认为的最优化的解决方案并不是开发者认为最优化的。因为Mysql只是基于成本模型选择最优的执行计划。
Mysql不会考虑其他的并发查询，可能会影响当前的查询速度。
Mysql有时候也会基于某些固定的规则来生成执行计划。
Mysql不会考虑不受控制的成本的，比如存储过程，用户定义的函数。

重新定义表的关联顺序，因为Mysql优化器会根据统计信息来决定表的关联顺序。
将外连接转换为内连接。
使用等价的规则变换。
优化count()、min()、max()等函数进行优化。
将一个表达式转换为一个常数。
子查询优化。
提前终止查询。
对in()条件进行优化。

如何确定Mysql在各个阶段所消耗的时间？
使用profile方法
使用set profiling=1启动profile，这是一个session级别的设置
执行查询
通过show profiles来查看每一个查询所消耗总时间的信息
通过show profile for query ID来查询第ID个阶段所消耗的时间
使用information_schema引擎
在Mysql5.5-开销较大，因此需要在配置文件修改。在Mysql5.7+以后就可以了。

update `setup_instruments` set enabled='YES', TIMED='YES' where name like 'stage%';
update `setup_consumers` set enabled='YES' where name like 'events%';

把一个实例中的多个数据库拆分到多个数据库实例中
把一个实例的数据库的表分离到不同实例的数据库中
对一个数据表进行分片水平拆分到不同的数据库实例中
1, 如何选择分区键
尽可能避免数据的跨分区查询的发生
分片键尽可能保证每个实例的数据是均衡的
2.如何存储不用分片的表
每个分片存储一份相同的数据，使用多写的方式更新数据
使用额外节点统一存储
3, 如何部署分片
每个分片使用单一的数据库，并且数据库名也相同
将多个分片的数据表存储在一个数据库中，并在表名中加入分片号后缀
在一个节点读个数据库，每个数据库包含一个分片
4. 如何分配分片的数据
通过分区键的Hash值取模来分配分片数据
按照分区键的范围来分配分片的数据
利用分区键和分区的映射表的方式来分配分片的数据，由于该映射表存在很大的读取压力，因此可以缓存该映射表
5. 如何生成分片以后的全局唯一ID
使得auto_increment_increment的值等于分片的数量，auto_increment_offset设置为不同的值
使用全局节点的方式来生成ID，但是该节点也会承受较大压力
在redis等缓存服务器中创建全局ID
使用oneProxy进行定制化开发

通过使用mysqladmin -umonitor_user -p -h ping来确认是否可以建立网络连接
使用telnet ip db_port来确认是否可以建立网络连接
通过检查数据库配置文件read_only来确认是否可以读写

通过show variables like 'max_connections';获取最大连接值
通过show global status like 'Threads_connected';获取已经连接的线程数
通过以上两个值的百分比确定是否报警

通过检查show slave status;来判断Slave_IO_Running和Slave_SQL_Running监控主从复制链路的状态。
监控主从复制延迟, 检查Seconds_Bebind_Master，但是数据不是特别准确。
通过在主库上获取日志文件名和偏移量和已经在主上传输完成的日志文件名和偏移量获取精确的值。
通过pt-table-checker来验证主从复制的数据是否一致。