关于mysql:Mysql优化篇

5次阅读

共计 1907 个字符，预计需要花费 5 分钟才能阅读完成。

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

次要字段
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）正当利用前缀索引，防止长字段索引过长，占用空间

这是 mysql5.6 版本之后外部对于索引过滤数据做的优化，实用于比方范畴查问，含糊查问，因为最左前缀准则，导致联结索引生效的状况。以前的查问都是在存储引擎层先返回条件字段索引相干的数据，而后间接回表，在 server 层再对 where 后生效的索引查问条件进行过滤，在 5.6 之后，在引擎层会对 where 索引条件进行筛选，进一步缩小了对记录的过滤（用艰深的话就是 5.6 版本之前联结索引中生效的索引字段会回表再去判断，ICP 会让判断条件从服务层下推至存储引擎层，对生效的索引字段在存储引擎层进行判断）。此时 explain select 语句的 extra 为 Using index condition（查找应用了索引，并且须要回表查问数据）。

将数据库分为主表和从表，主表作为写表，用于解决数据增删改和数据表操作，而从表作为读表个别会有多个，用于同步主表的批改，并且解决读操作。
主表 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 都是一样的。