mysql的优化实在太多,这里仅仅列一些常见的,不可能完全概括,后续有新学习的内容会持续更新。

explain 分析select语句

主要字段
select_type查询类型 eg:SIMPLE 简单查询,UNION 联合查询,SUBQUERY 子查询
table 查询的表
partitions:
type 索引查询类型 const:使用主键或者唯一索引进行查询的时候只有一行匹配 ref:使用非唯一索引 range:范围查询 all:扫描全表 index:和all的区别是扫描的是索引树 system表只有一行或空表,const的特例 fulltext:全文索引,优先级很高 等等
possible_keys 可能用到的索引
key 实际使用的索引
key_len 查询用到的索引长度(字节数)
ref 等值查询会显示const
rows 扫描的行数
filtered 表示存储引擎返回的数据在server层过滤后,剩下多少满足查询的记录数量的比例
extra :

  • Using index 查询不需要回表,并且where筛选条件是索引的是前导列
  • Using where Using index 查询不需要回表,并且where筛选条件是索引列之一但是不是索引的不是前导列,或者是前导列的一个范围查找
  • NULL 查询需要回表,并且where筛选条件是索引的前导列
  • Using where 查询需要回表,where筛选条件非索引的前导列,或者筛选条件非索引列
    等等

索引优化

(1)建立联合索引,讲选择性强唯一性高的字段放在前面,范围查找字段放在最后
(2)索引覆盖,尽量避免回表
(3)合理利用前缀索引,避免长字段索引过长,占用空间


索引下推ICP

这是mysql5.6版本之后内部对于索引过滤数据做的优化,适用于比如范围查询,模糊查询,因为最左前缀原则,导致联合索引后续索引字段失效。
以前的查询都是在存储引擎层先返回条件字段索引相关的数据,然后直接回表,在server层再对where后失效的索引查询条件进行过滤,在5.6之后,在引擎层会对where索引条件进行筛选,进一步增加了对记录的过滤(用通俗的话就是5.6版本之前联合索引中失效的索引字段会回表再去判断,ICP会让判断条件从服务层下推至存储引擎层,对失效的索引字段在存储引擎层进行判断,进一步筛选数据之后再回表)。此时explain select语句的extra为Using index condition(查找使用了索引,并且需要回表查询数据)。

核心是减少回表次数,将一些需要回表的判断放在存储引擎层进行。


MRR「Multi-Range Read Optimization」

随机磁盘读转换为顺序磁盘读


读写分离

将数据库分为主表和从表,主表作为写表,用于处理数据增删改和数据表操作,而从表作为读表一般会有多个,用于同步主表的修改,并且处理读操作。
主表master和从表slave通过binlog来同步。我们知道,对于主表的修改会写入binlog,此时主表会开启一个binlog dump线程,将修改的binlog发送给从表的IO线程,从表会将binlog写入relay log,之后sql线程会将修改的部分同步到从表。

读写分离带来的主从表数据不一致问题怎么解决?
可以采用 1.从主表读取未同步的数据 2.延迟读 等等方法。


分库分表

分表

  • 垂直分表
    按照字段进行分表,使用频率高的字段放在一张表,使用频率低的放另一张表,同时,两张表都要有相同的主键id。
    垂直分表的意义在于,表的最大尺寸是和字段数相关的,如果垂直拆分字段成不同的表,字段数下降了,表的最大尺寸则变大了,能容纳更多数据。
  • 水平分表
    根据一个规则或字段(分片键)将数据分到不同的表里,保证所有表的字段都相同,数据均匀划分。

分库

  • 业务模块分库
    根据不同的业务模块来分库,将不同业务的数据库操作分隔开来
  • 按表分库
    对于上述水平分表产生的多个子表来说,可以将不同的子表分到不同的数据库中

分库分表也会带来一些问题,比如:

  • 不同库表关联查询问题
    首先设计初需要避免这种情况,如果出现这种情况
    1.设计冗余字段,避免跨库的join
    2.添加全局表,保存一些全局数据等很少修改的数据
  • 分布式事务问题
    基于两阶段提交的XA事务
  • 分布式id问题
    可以利用雪花算法,或者专门的id生成服务解决
  • 数据扩容
    因业务量增加需要增加子表,这个时候需要重新设置分片规则,并且做数据迁移,保证数据均匀分布
  • 跨表排序分页
    分片键作为排序字段,则正常使用排序;反之,则需要在不同子表中分别查询结果并汇总,再次排序
  • ER分片
    对于一些关联表,可以合理设置它们的分片字段,使得相同分片数据的表在同一个数据分片上,避免跨库join。比如员工表和公司表,假设他们以公司id关联,可以以公司id来分片,这样能保证同一个库内,公司表和员工表的公司id都是一样的。

此外,这些问题可以利于一些市面上成熟的中间件来解决,比如ShardingSphere,mycat,Sharding-JDBC,DRDS等等。


发条橙
55 声望0 粉丝

But every once in a while you find someone who's iridescent, and when you do, nothing will ever compare


« 上一篇
Mysql-其他篇
下一篇 »
Spring IOC过程