mysql学习篇

本次学习是根据网络课程《打造扛得住的MySQL数据库架构》

于2020年02月学习

---

前言：

本人建议如果有兴趣学习这门网络课程，因先有基础的mysql数据库的一些知识，至少你会用它。我认为本篇网络课程中，拓展知识为主，并非专门研究某一个细的点，本门网络课程是一门讲解和经验讨论的课程，如果想学习相应的专门的模块，还需自行阅读相关资料。

加之本人这篇博文更像学习笔记，并非常规的研究型博文。

以上是本人的见解，并非准确，参考即可，若有不妥请点明。

---

目录

前言：

一、影响服务器的几个因素

二、mysql服务器参数

三、数据库结构设计

四、数据库复制功能

五、数据库结构设计

六、索引

七、sql查询优化

八、数据库分库分表

九、数据库监控

---

---

一、影响服务器的几个因素

1. 硬件问题：

   1. 硬盘的因素
      1. 机械硬盘
      2. SSD
2. 网络和io资源（内存）等因素
3. cpu因素
   1. 在经费允许的情况下，CPU应尽可能多主频、多核心
   2. 如果是计算密集型则选择多主频，反之则多核心
   3. 服务器系统因素
      1. 服务器系统的选择；（CentOS为主要选择）
4. 数据库存储引擎的选择
   1. 在mysql中有多种存储引擎选择，Innodb、MyISAM、MEMORY、ARCHIVE、CSV等；
   2. 不同的存储引擎都有不同的适应场景；
   3. 选择错误的存储引擎可能导致严重的问题；
   4. 数据库参数配置
      1. 错误的参数配置可能导致数据库宕机、性能损耗等
5. 数据库结构设计和sql语句
   1. 不合理的数据库结构设计会极大影响数据库的性能
   2. 不合理的sql语句也会极大的影响数据库的性能
6. 锁
   1. 简单解释
      1. 管理共享资源的并发访问
      2. 用于实现事务的隔离性
   2. 锁的类型
      1. 共享锁（读锁）
      2. 独占锁（写锁）
   3. 锁的粒度
      1. 表级锁
      2. 行级锁

二、mysql服务器参数

1. 全局参数和会话参数
   1. set global
   2. set session
2. 内存配置

   1. 确定可以使用的内存的上限

   2. 确定MySQL的每个连接使用的内存

      1. sort_buffer_size 排序缓存区内存大小，不宜过大，mysql是固定给每次新的都增加这么多内存，连接数过大容易溢出崩溃

      2. join_buffer_size 连接缓冲区的尺寸，每个连接可能出现多个缓存，

      3. read_buffer_size mysam表全表扫描时创建，

      4. read_rnd_buffer_size 索引缓冲区的大小，

   3. 确定需要为操作系统保留多少内存

   4. 如何为缓存池分配内存

      1. innodb_buffer_pool_size ：如果只用innodb表，那么可以使用以下方程：总内存-(每个线程所需要的内存*连接数)-系统保留内存 （标准：服务器内存的75%以上）

      2. key_buffer_size ： mysam索引缓存

3. io配置

   1. innodb I/O相关配置

      1. innodb_log_file_size：单个恢复日志大小

      2. innodb_log_file_in_group：

      3. innodb_log_buffer_size：日志缓冲区32MB-128MB就足够

      4. innodb_flush_log_at_trx_commit：

         1. 0：每秒进行一次log写入cache，并flush log到磁盘

         2. 1：默认操作，在每次事务提交执行log写入cache，并flush log到磁盘

         3. 2：建议，每次事务提交，执行log数据写入到cache，每秒执行一次flush log到磁盘

      5. innodb_flush_method=O_DIRECT (linux建议)

      6. innodb_file_per_table = 1 （如何使用表空间，1就是每个都建立）

      7. innodb_doublewrite = 1 (应设置，避免发生数据安全问题)

   2. MyISAM：

      1. delay_key_write

         1. off

         2. on

         3. all

4. 安全配置

   1. expire_logs_day ：指定自动清理binlog的天数（保存7天左右）

   2. max_allowed_packet ： 控制mysql可以接受包的大小

   3. skip_name_resolve： 禁用DNS查找

   4. sysdate_is_now 确保sysdate()返回确定性日期

   5. read_only 禁止非super权限的用户写权限

   6. skip_slave_start : 禁用Slave自动恢复

   7. sql_mode ：设置MySQL所使用的SQL模式（谨慎休息）

      1. strict_trans_tables

      2. no_engine_subtiyution

      3. no_zero_date

      4. no_zero_in_date

      5. only_full_group_by

5. 其他常用配置

   1. sync_binlog 控制MySQL如何向磁盘刷新binlog

   2. tmp_table_size和max_heap_table_size 控制内存临时表大小，设置一致

   3. max_connections 控制允许的最大连接数（可以来考虑设置值 1000）

6. 数据库设计对性能的影响

   1. 过分的反范式化为表建立太多的列

   2. 过分的范式化造成太多的表关联

   3. 在OLTP环境中使用不恰当的分区表（并不是分库分表）

   4. 使用外键保证数据的完整性

7. 小结：

   1. 数据库优化的优先级：

      1. 数据库结构设计和sql语句

      2. 数据库存储引擎的选择和参数配置

      3. 系统选择及优化

      4. 硬件升级

8. mysql基准测试介绍

   1. 基准测试（简化压力测试）

      1. 建立MySQL服务器的性能基准线

      2. 模拟比当前系统更高的负载，以找出系统的扩展瓶颈

      3. 测试不同的硬件、软件和操作系统配置

      4. TPS：单位时间内所处理的事务数

      5. QPS单位时间内所处理的查询数

      6. 响应时间

         1. 平均响应时间、最小响应时间、最大响应时间、各时间所占百分比

         2.  

      7. 并发量：同时处理的查询请求的数量（不等同于web并发量）

   2. 自带的mysqlslaps

   3. sysBench

   4. 压力测试

三、数据库结构设计

1. 优秀的结构设计带来的好处

   1. 减少数据冗余

   2. 尽量避免数据维护中出现更新，插入和删除异常

      1. 插入异常：如果表中的某个实体随着另一个实体而存在

      2. 更新异常：如果更改表中的某个实体的单独属性时，需要对多行进行更新

      3. 删除异常：如果删除表中的某一个实体则会导致其他实体的消失

   3. 节约数据存储空间

   4. 提高查询效率

2. 数据库结构设计的步骤

   1. 需求分析

   2. 逻辑设计

   3. 物理设计

      1. 定义数据库、表及字段的命名规范

      2. 选择合适的存储引擎

      3. 为表中字段选择合适的数据类型

         1. 优先：数字类型->日期或二进制类型->字符

         2. 优化：空间小的数据类型

         3. varchar和char

         4. 日期类型

            1. datatime

            2. timestamp（有一定范围内），空间小；(和时区有关)

            3. date 存储日期部分，占用空间少，进行日期函数计算

            4. time 存储时间部分，

            5. 注意事项

               1. 不要使用字符串类型来存储日期时间数据

                  1. 日期时间类型通常比字符串占用的存储空间小

                  2. 日期时间类型进行查找过滤时可以利用日期来进行对比

                  3. 日期时间类型还有着丰富的处理函数，可以方便的对时期类型进行日期计算

               2. 使用int存储日期时间不如使用timestamp类型

      4. 建立表的结构

3. 数据库表设计
   1. 三范式

      1. 第一范式

         1. 数据库表中的所有字段都只具有单一属性

         2. 单一属性的列是由基本的数据类型所构成

         3. 设计出来的表都是简单的二维表

      2. 第二范式

         1. 要求一个表中只具有一个业务主键，也就是说符合第二范式的表中不能存在非逐渐列对只对部分逐渐的依赖关系

      3. 第三范式

         1. 指每一个非主属性既不部分依赖也不传递依赖于业务主键，也就是在第二范式的基础上消除了非主属性对主键的传递依赖

   2. 反三范式
      1. 在业务处理中根据实际情况有时也需要进行反三范式的设计，这样的设计是为了更高的效率，节省不必要的连表查询
   3. 各自优缺点

      1. 范式化利好于写，难以维护索引

      2. 反范式化利于查，便于索引维护

四、数据库复制功能

1. 二进制日志

   1. 基于段的日志格式 binlog_format = STATEMENT （SBR）

   2. 基于行的日志格式 binlog_format = ROW(默认) （RBR）

      1. 使mysql主从复制更加安全

      2. 但是消耗磁盘io，存量大

      3. 附加操作：binlog_row_image = [FULL\MINIMAL\NOBLOB]

   3. 混合日志格式 binlog_format = MIXED 

      1. 根据sql语句由系统决定在基于段和行的日志格式中进行选择

      2. 数据量大小由所执行的sql语句决定

   4. 建议使用row格式为主，建议binlog_row_image为minimal

2. 日志格式对于复制的影响

3. 配置mysql复制

   1. 基于日志点的复制

      1. 设定相应的复制账号并授权

      2. 配置主服务器（配置文件）

         1. bin_log = mysql-bin

         2. server_id = 100

      3. 配置从服务器

         1. bin_log = mysql-bin

         2. server-id = 101

         3. relay_log = mysql-relay-bin

         4. log_slave-update = on [可选]

         5. read_only = on [可选]最好选择配置

      4. 初始化从服务器

         1. mysqldump -uroot -p --single-transaction --master-data=2 --triggers --routines --all-databases >>all2.sql (可能存在很大的阻塞)

         2. xtrabackup --slave-info (非innodb表会锁表，innodb不会锁表)推荐使用

         3. 拷贝 mysql -uroot -p < xxx.sql

      5. 启动复制链路(在从服务器上)

         1. change master to master_host='master_host_ip',master_user='repl',master_password='password',master_log_file='mysql_log_file_name',master_log_pos=4;

         2. start slave;

      6. 优点：

         1. 是MySQL最早支持的复制技术，bug相对较少

         2. 对sql查询没有任何限制

         3. 故障处理比较容易

      7. 缺点：

         1. 故障转移时重新获取新主的日志点信息比较困难

   2. 基于GTID复制

      1. mysql5.6开始支持

      2. 全局事务id，其保证为每一个在主上提交的事务在复制集群中可以生成一个唯一的id

      3. 在主DB服务器上建立复制账号

      4. 配置主服务器（配置文件）

         1. bin_log = /*/mysql-bin

         2. server_id = 100

         3. gtid_mode = on (关键参数)

         4. enforce-gtid-consistency = on

         5. log-slave-updates = on 

      5. 配置从服务器

         1. server-id = 101

         2. relay_log = /*/relay_log

         3. gtid_mode = on

         4. enforce-gtid-consistency = on 

         5. log_slave-update = on

         6. read_only = on [可选]最好选择配置

         7. master_info_repository = TABLE[建议]

         8. raley_log_info_repository = TABLE[建议]

      6. 初始化服务器数据

      7. 启动GTID的复制

         1. change master to master_host='master_host_ip',master_user='repl',master_password='password',MASTER_AUTO_POSITION = 1, get_master_public_key=1;(mysql8中需要加最后一个，是密码的问题；)

         2. start slave;

      8. 优点：

         1. 可以很方便的进行故障转移

         2. 从库不会丢失主库上的任何修改

      9. 缺点：

         1. 故障处理比较复杂

         2. 对执行的sql有一定的限制

   3. 如何选择复制模式

      1. 所使用的MySQL版本（5.6以后的版本适合GTID）

      2. 复制架构及主从切换的方式

      3. 所使用的高可用管理组件

      4. 对应用的支持程序（GTID对sql的限制）

   4. mysql复制拓扑

      1. mysql5.7之前只能一个主库，以后可以多个主库

      2. 一主多从复制拓扑

         1. 配置简单

         2. 可以用多个库分担读负载

         3. 为不同业务使用不同的从库（例如前后台查询）

         4. 将一台从库放到远程IDC，用作灾备恢复

         5. 分担主库读负载

      3. 主-主复制拓扑

         1. 注意事项

            1. 产生数据冲突而造成复制链路的中路

            2. 耗费大量时间

            3. 造成数据丢失

            4. 两个主中所操作的表最好分开

            5. 使用下面两个参数控制自增ID的生成

               1. auto_increment_increment = 2  （自增id 的间隔）

               2. auto_increment_offset = 1|2 （自增id的生成基数）

      4. 主备模式复制拓扑

         1. 注意事项

            1. 确保两台服务器上的初始数据相同

            2. 确保两台服务器上已经binlog并且有不同的server_id

            3. 在两台服务器上启用log_slave_updates参数

            4. 在初始的备库上启用read_only

      5. 级联复制

   5. mysql复制性能优化

      1. 影响的因素：

         1. 主库写入二进制日志的时间

            1. 控制主库的事务大小，分割大事务

         2. 二进制日志传输的时间

            1. 使用mixed日志格

            2. 设置 binlog_row_image=minimal

         3. 默认情况下从只有一个sql线程，主上并发的修改在从上变成可串行

            1. 使用多线程复制（在mysql5.7中可以逻辑时期）

               1. stop slave;

               2. set global slave_parallel_type='logical_clock';

               3. set global slave_parallel_worker=4;

               4. set slave;

   6. mysql复制常见问题处理

      1. 由于数据损坏或丢失所引起的主从复制错误

      2. 主库上的二进制日志损坏

      3. 备库上的中继日志损坏

      4. 在从库上进行数据修改造成的主从复制错误

      5. 不唯一的server_id或server_uuid

      6. max_allow_packet设置引起的主从复制错误

      7. 无法分担主数据库的写负载

         1. 分库分表

      8. 无法自动进行故障转移及主从切换

      9. 无法提供读写分离功能

五、数据库结构设计

1. 高可用架构设计
   1. 5个9、4个9、3个9

   2. MMM架构

      1. 优点：

         1. 使用perl脚本语言开发及完全开源

         2. 提供了读写vip（虚拟ip），使服务器角色的变更对前端应用透明

         3. 提供了从服务的延迟监控

         4. 提供了主数据库故障转移后从服务器对新主的重新同步功能

         5. 很容易对发生故障的主数据库重新上线

         6. 提供了从服务器监控

      2. 缺点：

         1. 发布时间比较早不支持MySQL新的复制功能（GTID复制功能不支持，多线程复制不支持）

         2. 没有读负载均衡的功能

         3. 在进行主从切换时，容易造成数据丢失

         4. MMM监控服务存在单点故障

   3. MHA架构

      1. 现在主从上建立好gtid链路

      2. 建立ssh免密登录

      3. 下载MHA node安装包

      4. 安装perl的相关软件包

      5. 安装MHA node软件包

      6. 配置MHA

         1. 只需要在管理点配置即可

            1. server default

               1. user=mha

               2. password=123456

               3. manager_workdir=/***/mysql_mha

               4. manager__log=/***/manager.log

               5. remote_workdir=/**/mysql_mha

               6. ssh_user=root

               7. repl_user=repl

               8. repl_password=123456

               9. ping_interval=1

               10. master_binlog_dir=/**/***

               11. master_ip_failover_script=

               12. secondary_check_script=/

            2. server1

               1. hostname=192.168.3.**

               2. candidate_master=1(可以参加主服务器的候选)

            3. server2

               1. hostname=192.168.3.**

               2. candidate_master=1(可以参加主服务器的候选)

            4. server3

               1. hostname=192.168.3.**

               2. no_master=1（不可以参数主服务器候选）

      7. 启动MHA nohup master_manager --conf=/etc/mha/mysql_mha.cnf（指定配置文件）

      8. 优点：

         1. 使用perl脚本语言开发及完全开源

         2. 可以支持基于GTID的复制模式

         3. MHA在进行故障转移时更不易产生数据丢失

         4. 同一个监控节点可以监控多个集群

      9. 缺点

         1. 需要编写脚本或利用第三方工具来实现vip的配置

         2. MHA启动后只会对主数据库进行监控

         3. 需要基于SSH免认证配置，存在一定的安全隐患

         4. 没有提供从服务器的读负载均衡

2. 读写分离和负载均衡

   1. 由程序实现读写分离

      1. 优点：

         1. 由开发人员控制什么样查询在从库中执行，由此比较灵活

         2. 由程序直接连接数据库，所以性能损耗比较少

      2. 缺点：

         1. 增加开发量，是程序代码复杂

         2. 人为控制，容易出现错误

   2. 由第三方中间件读写分离

      1. mysql-proxy

      2. MaxScale----MariaDB 

      3. 优点

         1. 由中间件根据查询语法分析，自动完成读写分离

         2. 对程序透明，对已有程序不用做任何调整

      4. 缺点

         1. 由于增加中间层，所以对查询效率有损耗（高并发才会严重体现）

         2. 对于延迟敏感业务无法自动在主库执行

   3. MaxScale

      1. 认证插件

      2. 协议插件

      3. 路由插件

         1. readconnroute

         2. readwritesplit

      4. 监控插件

      5. 日志和过滤插件

      6. 安装

         1. 下载软件包

         2. yum 相关支持包

         3. rpm 安装

六、索引

1. B-tree索引

   1. 能够加快数据的查询数据

   2. 更适合进行范围查找

   3. 什么情况会使用：

      1. 全值匹配的查询

      2. 匹配最左前缀的查询

      3. 匹配列前缀查询

      4. 匹配范围值的查询

      5. 精确匹配左前列并范围匹配另外一列

      6. 只访问索引的查询

   4. 使用限制

      1. 如果不是按照索引最左列开始查找，则无法使用索引

      2. 使用索引时不能跳过索引中的列

      3. not in 和 <> 操作无法使用索引

      4. 如果查询中有某个列的范围查询，则其右边所有列都无法使用索引

2. Hash索引

   1. Hash索引是基于Hash表实现的，只有查询条件精确匹配Hash索引中的所有列时，才能够使用到Hash索引

   2. 对于Hash索引中的所有列，存储引擎都会为每一行计算一个Hash码，Hash索引中存储的就是Hash码

   3. 限制：

      1. hash索引必须进行二次查找（先找hash码再匹配值）

      2. hash索引无法用于排序

      3. hash索引不支持部分索引查找也不支持范围查找

      4. hash码可能存在hash冲突（不能在数据值差别不大的列上建立索引）

3. 使用索引带来的好处

   1. 索引大大减少了存储引擎需要扫描的数据量

   2. 索引可以帮助我们进行排序以避免使用临时表（B-TREE索引）

   3. 索引可以把随机I/O变成顺序I/O

4. 索引带来的损耗

   1. 索引会增加写操作的成本

   2. 太多的索引会增加查询优化器的选择时间

5. 建立索引的策略

   1. 索引列上不能使用表达式或函数

   2. 前缀索引和索引列的选择性（索引的选择性）

      1. create index index_name on table(col_name(n)) （innodb有700多的大小限制）

      2. 索引的选择性是不重复的索引值和表的记录数的比值（主键索引和唯一索引是最好的索引选择）

   3. 联合索引（如果每一个都建立索引会使得索引过大）

      1. 选择索引列的顺序很重要（mysql优化器是where条件从左到右识别索引的）

         1. 经常会被使用到的列优先，放在最左边

         2. 但是如果是数据差别性很小的列（例如性别），也不适合放在最左边

         3. 宽度小的列优先（不违反选择性的原则下）

   4. 覆盖索引

      1. 优点

         1. 可以优化缓存，减少磁盘IO操作

         2. 可以减少随机IO，变随机IO操作变为顺序IO操作

         3. 可以避免对Innodb主键索引的二次查询

         4. 可以避免MyISAM表进行系统调用

      2. 缺点

         1. 某些存储引擎不支持覆盖索引

         2. 查询中使用了太多的列

         3. 使用了双%%号的like查询

6. 使用索引来优化查询

   1. 索引索引扫描来优化排序

      1. 通过 order by

      2. 按照索引顺序扫描数据

         1. 索引的列顺序和Order By子句的顺序完全一致

         2. 索引中所有列的方向（升序、降序）和Order by子句完全一致

         3. Order by中的字段全部在关联表中的第一张表中

   2. 使用B-TREE索引模拟Hash索引优化查询

      1. 只能处理键值的全值匹配查找

      2. 所使用的Hash函数决定着索引键的大小

   3. 利用索引优化锁

      1. 索引可以减少锁定的行数

      2. 索引可以加快处理速度，同时也加快了锁的释放

7. 索引的维护和优化

   1. 删除重复和冗余的索引

      1. primary key（主键索引），unique key（唯一索引），index（单列索引） 一个列上建立多个索引

      2. index(a),index(a,b) 创建联合索引，造成冗余的索引

      3. primary key(id), index(a,id) 创建联合索引，造成了冗余的索引

   2. pt-duplicate-key-checker h=127.0.0.1 使用工具来检查重复索引和冗余索引

   3. 查找未被使用过的索引

      1. 利用sql来查找表的索引使用次数

   4. 更新索引统计信息及减少索引碎片

      1. analyze table table_name（innodb引擎中查找的值可能是估算值）

      2. optimize table table_name（减少索引碎片和表的碎片，但是使用不当可能会锁表）

七、sql查询优化

1. 获取有性能问题sql的三种方法

   1. 通过测试/用户反馈获得存在性能问题的sql

   2. 通过慢查询日志获取存在性能问题的sql

   3. 实时获取存在性能问题的sql

2. 慢查询日志

   1. slow_query_log = on 启动慢查询日志

      1. 可以通过脚本定时开启

   2. slow_query_log_file = /**/slow_query_log  指定慢查询日志的存储路径及文件

   3. long_query_time = 0.001秒(单位是秒,默认10秒) 指定记录慢查日志sql执行时间的阀值

   4. long_queries_not_using_indexes =  是否记录未使用索引的sql

   5. 常用的慢查日志分析工具

      1. mysqldumpslow 官方附带

      2. pt-query-digest \ 

      3. 尽可能在从服务器执行慢查询日志（但是如果是写的话，还是要主服务器）

3. 实时获取性能问题sql

   1. SELECT id,'user','host',DB,command,'time',state,info FROM information_schema.PROCESSLIST WHERE TIME >= 60秒（）

4. sql的解析预处理及生成执行计划

   1. sql处理的阶段

      1. 客户端发送sql请求给服务器

      2. 服务器检查是否可以在查询混存中命中该sql

         1. 通过Hash大小敏感在内存中查找

         2. 用户权限

         3. 对缓存加锁，降低查询处理的效率（对读写较为频繁的系统，还是建议关闭查询缓存）

         4. query_cache_type 设置查询缓存是否可用

         5. query_cache_size 设置查询缓存的内存大小

         6. query_cache_limit 设置查询缓存可用存储的最大值

         7. query_cache_wlock_invalidate 设置数据表被锁后是否返回缓存中的数据(默认关闭)

         8. query_cache_min_res_unit 设置查询缓存分配的内存块最小单位

      3. 服务器端进行sql解析，预处理，再由优化器生成对应的执行计划

         1. 解析sql

         2. 预处理

         3. 优化sql执行计划（可能影响mysql执行计划的因素）

            1. 统计信息不准确

            2. 执行计划中的成本估算不等同于实际的执行计划的成本

               1. mysql服务器层并不知道哪些页面在内存中

               2. 哪些页面在磁盘上

               3. 哪些需要顺序读取

               4. 哪些页面需要随机读取

            3. mysql优化器所认为的最优可能与你所认为的最优不一样

               1. mysql是基于成本模型选择最优的执行计划---往往可能不是最快的执行计划

            4. mysql从不考虑其他并发的查询，这可能会影响当前查询的速度

            5. mysql有时候也会基于一些固定的规则来生成执行计划

               1. 例如符合全文索引的可能会执行全文索引

            6. mysql不会考虑不受其控制的成本

               1. 存储过程、用户自定义的函数等

         4. mysql查询优化器可优化的sql类型

            1. 重新定义的表的关联顺序

               1. 优化器会根据统计信息来决定表的关联顺序

            2. 将外连接转化为内连接

               1. where条件和库表结构

            3. 使用等价变化规则

            4. 优化count()、min()和max()

               1. 利用B-TREE索引来查询最小值或者最大值

               2. mysql如果执行此次处理可能会在执行计划出现：select tables optimized away （优化器已经从执行计划中移除了该表，并以一个常数取而代之）

               3. 例如对MyISAM表进行count()处理时，会使用MyISAM引擎的特性查询一个常数来返回统计值。

            5. 将一个表达式转化为常数表达式

            6. 使用等价变换规则

            7. 子查询优化（某些情况下）

               1. 转换为关联查询

            8. 提前终止查询

               1. 使用了limit查询

               2. 如果优化器能了解sql语句会返回null值，会提前终止查询，例如查询id=-1，但是id不会为负值的情况下，优化器会终止查询

            9. 对in()条件进行优化

      4. 跟踪执行计划，调用存储引擎API来查询数据

      5. 将结果返回给客户端

5. 确定查询处理各个阶段所消耗的时间

   1. 使用profile

      1. set profiling = 1;（session级配置）启动profiles命令

      2. show profiles; 查看每一个查询所消耗的总时间的信息

      3. show profiles for query N;查询每个阶段所消耗的时间

      4. show profiles cpu for query 1(query_id); 查询cpu的信息

      5. show profiles mysql 官方不推荐使用，推荐使用以下另一种方式去查询会更好，而且该命令可能会在以后的版本中被移除；

   2. 使用performance_schema（5.6以后开销就会好很多了）

      1. 启动需要执行两个update语句，打开监控、历史记录表的信息

         1. UPDATE 'setup_instruments' SET enabled='YES',TIMED='YES' WHERE NAME LIKE 'stage%';

         2. UPDATE setup_consumers SET enabled='YES' WHERE NAME LIKE 'events%';

      2. 只要执行了sql就是对全局有效的

      3. 查询语句

6. 特定sql的查询优化

   1. 大表的数据修改最好要分批修改

   2. 修改大表的表结构

      1. 对表中的列的字段类型进行修改、改变字段的宽度时还是会锁表

      2. 利用老表建立一个新表，同步数据，同时对老表建立一个触发器，使老表新增数据时同步到新表中，当两个表数据相同时，对老表加排他锁，然后进行老表和新表的名称互换，达成修改表结构的目的；

      3. 可以利用工具 pt-online-schema-change 

   3. 如何优化not in 和 <>查询

      1. 使用left join 优化 not in

   4. 使用汇总表优化查询

      1. 数据量大的时候count()会很慢

      2. 使用建立一个汇总统计表，每天固定时间执行存储过程收集数据

      3. 查询当前统计数据时，就可以将汇总统计表的记录+新增加的记录数，由于查询新增加的记录数时应该是会用了条件查询语句，那么就可能使用了相应的索引（覆盖索引），因此效率就会大大提升；

八、数据库分库分表

1. 数据库分库分表的几种方式

   1. 把一个实例中的多个数据库拆分到不同的实例

   2. 把一个库中的表分离到不同的数据库中

2. 数据库分片

   1. 对一个库中的相关表进行水平拆分到不同实例的数据库中

   2. 如何选择分区键

      1. 分区键要能尽量避免跨分片查询的发生

   3. 如何存储无需分片的表

      1. 每个分片中存储一份相同的数据

   4. 使用额外的节点统一存储

   5. 如何在节点上部署分片

      1. 每个分片使用单一数据库，并且数据库名也相同

      2. 将多个分片表存储在一个数据库中，并在表名上加入分片号后缀

      3. 在一个节点中部署多个数据库，每个数据库包含一个分片

   6. 如何分配分片中的数据

      1. 按分区键的hash值取模来分配分片数据

      2. 按分区键的范围来分配分片数据

      3. 利用分区键和分片的映射表来分配分片数据

   7. 如何生成全局唯一ID

      1. 使用auto_incremment_increment 和 auto_increment_offset 参数

      2. 使用全局节点来生成ID

      3. 在redis等缓存服务器中创建全局ID

3. oneProxyp分片工具（并不完美）

4. 后续会有专门的一章去学习MyCat

九、数据库监控

1. 对数据库服务可用性进行监控

   1. 如何确认数据库是否可以通过网络

      1. mysqladmin -umonitor_user -p -h ping

      2. telnet ip db_port

      3. 使用程序通过网络建立数据库连接（最好的方式，模拟应用程序连接数据库）

   2. 如何确认数据库是否读写

      1. 检查数据库的read_only参数是否为off

      2. 建立监控表并对表中数据进行更行

      3. 执行简单的查询 select @@version

   3. 如何监控数据库的连接数

      1. show variables like 'max_connections'；

      2. show global status like 'Threads_connected'；

      3. Threads_connected / max_connections >0.8 

2. 对数据库性能进行监控

   1. 记录性能监控过程中所采集到的数据库的状态

   2. 如何计算QPS和TPS

   3. 如何监控数据库的并发请求数量

      1. 数据库系统的性能会随着并发处理请求数量的增加而下降

      2. show global status like 'Threads_running'

      3. 并发处理的数量通常会远小于同一时间连接到数据库的线程的数量

   4. 如何监控innodb的阻塞

      1. 可以利用sql查询innodb引擎下线程阻塞时间，可能无法抽取阻塞的sql（sql已经执行完的情况下）

3. 对主从复制进行监控

   1. show slave status

   2. 监控主从复制延迟

   3. 使用多线程的程序同时对于主从服务器的状态来检查

   4. 如何验证主从复制的数据是否一致

      1. pt-table-checksum 

4. 对服务器资源的监控

（未完待续；………………）