说说你是如何进行mysql调优的

开发前期 —mysql设计初期的优化

三范式的设计

前期需要对项目数据库进行合理的需求分析和概念设计，那就一定离不开三范式。

第一范式1NF：确保每个字段保持原子性，不可分割。

第二范式2NF：确保字段完全依赖于主键。

第三范式3NF：在满足第二范式的前提下，实体中每个属性与主键直接相关而不能间接相关。

适当的情况下利用数据冗余：为了提高查询效率允许反三范式的出现

字段大小的优化

说到调优，从我们mysql表的初期设计就已经开始进行调优的考虑了，初期设计时，考虑到表的每个字段用多大的量，这些一定要严格把控，不能说varchar类型上来就弄个255，这样太浪费空间了！

为什么要控制单行数据的大小。

目的是为了让三层的B+树承载更多的数据量

在B+树中，非叶子节点上不存放表数据，因此在B+树中每个非叶子节点（磁盘块）中的数据页能存储更多的键值，一个键值才14B（8字节大小的bigint + 6字节向下的指针），而一个表数据差不多1k

拿一个三层的B+树来举例，一个根节点能存储1170个数据（16*1024 /14)，1170个id+指针，第二层能存放1170的平方个数据136万个

那么问题来了，在叶子节点层中会有136w个叶子节点，每个节点16kb，如果一条mysql的数据没有好好规划大小一条数据如果16kb，那么三层B+树只能存储100w条数据。如果我们好好规划它的大小，维持在一条数据1kb，那么三层B+树会存储1000w+条数据

因此，一定要根据需求严格控制大小，在于B+树的高扇出性

开发中期— 慢sql的优化，索引的优化

如果出现慢sql就需要通过我们的慢查询日志分析采集到的慢sql语句了，看看有没有出现索引失效或全表扫描的情况，这时合理的利用索引和设计索引就显得尤为重要

索引的分类

主键索引（聚簇索引）、辅助索引（普通索引、唯一索引）、 组合索引

介绍索引覆盖防止回表，全值匹配利用到索引下推

如何避免索引失效

介绍下慢查询日志->explain功能 -> 什么时候适合/不适合创建索引

介绍防止索引失效：lol (like or 联合索引),±*/ ,not , null , in convert , on method

开发后期 — 大数据量mysql的优化问题

从mysql分区的角度

随着数据量的增长，需要对mysql的数据进行partition分区，这个是根据业务需求决定的，比如按照id的分区，按照日期的分区，单台机器最多支持1024个分区

从分库分表的角度

如果数据量实在过大，分区是无法支撑的，需要进行分库分表。

先垂直拆分，如果垂直拆分后，还是无法满足单台服务器的性能需求，就需要水平拆分

• 垂直分表

  垂直分表一定要注意数据的关联性（关联字段），垂直分表最好是拆分以后，各个拆分后的表都能支持整条业务线

• 水平分表

  水平分表一定伴随着水平分库

  水平分表复杂度最高，复杂点在于如何将不同的数据分配到不同的mysql服务器（不同的库）里面，此时用日期就不行了，需要按照业务需求了，有可能极端情况下需要批查询数据，一个查询请求会查询多个数据库，因此考虑合适的字段作为水平拆分标准尤为重要。避免单个sql查询多个库

冷热数据备份的角度

冷数据进行实时的备份，冷数据，如果数据距离当前时间较久的不需要进行查询的，将其进行备份