MySQL优化
Sql慢的原因
-
查询语句写的烂
-
索引失效：
- 单值索引：在user表中给name属性建个索引，
create index idx_user_name on user(name) - 复合索引：在user表中给name、email属性建个索引，
create index idx_user_nameEmail on user(name,email)
- 单值索引：在user表中给name属性建个索引，
-
关联查询太多join(设计缺陷或不得已的需求)
-
服务器调优及各个参数设置(缓冲、线程数等)
SQL语句执行顺序
手写顺序：
MySQL优化后的实际执行顺序（常见，非一定）：
常见的join连接查询
其中，MySQL不支持full join，因此最底下两个SQL语句可以修改为为：SELECT <select_list> FROM TableA A LEFT JOIN TableB B on A.Key = B.Key union SELECT <select_list> FROM TableA A RIGHT JOIN TableB B;
SELECT <select_list> FROM TableA A LEFT JOIN TableB B on A.Key = B.Key WHERE A.Key IS NULL union SELECT <select_list> FROM TableA A RIGHT JOIN TableB B WHERE B.Key IS NULL;
索引
索引是什么
- MySQL官方对索引的定义为：索引(Index)是帮助MySQL高效获取数据的数据结构。可以得到索引的本质：索引是数据结构
- 你可以简单理解为"排好序的快速查找数据结构"，即索引 = 排序 + 查找
- 一般来说索引本身占用内存空间也很大，不可能全部存储在内存中，因此索引往往以文件形式存储在硬盘上
- 我们平时所说的索引，如果没有特别指明，都是指B树(多路搜索树，并不一定是二叉树)结构组织的索引。
- 聚集索引，次要索引，覆盖索引，复合索引，前缀索引，唯一索引默认都是使用B+树索引，统称索引。当然，除了B+树这种类型的索引之外，还有哈希索引(hash index)等。
索引原理
-
将索引理解为"排好序的快速查找数据结构"
-
在数据之外，数据库系统还维护着满足特定查找算法的数据结构，这些数据结构以某种方式引用（指向）数据，这样就可以在这些数据结构上实现高级查找算法。这种数据结构，就是索引。
-
下图就是一种可能的索引方式示例：
-
左边是数据表，一共有两列七条记录，最左边的十六进制数字是数据记录的物理地址
-
为了加快col2的查找，可以维护一个右边所示的二叉查找树，每个节点分别包含索引键值和一个指向对应数据记录物理地址的指针，这样就可以运用二叉查找在一定的复杂度内获取到相应数据，从而快速的检索出符合条件的记录。
-
索引的优劣势
优势：
- 类似大学图书馆的书目索引，提高数据检索效率，降低数据库的IO成本
- 通过索引列对数据进行排序，降低数据排序成本，降低了CPU的消耗
劣势：
- 实际上索引也是一张表，该表保存了主键和索引字段，并指向实体表的记录，所以索引列也是要占用空间的
- 虽然索引大大提高了查询速度，同时却会降低更新表的速度，如果对表INSERT，UPDATE和DELETE。因为更新表时，MySQL不仅要不存数据，还要保存一下索引文件每次更新添加了索引列的字段，都会调整因为更新所带来的键值变化后的索引信息
- 索引只是提高效率的一个因素，如果你的MySQL有大数据量的表，就需要花时间研究建立优秀的索引，或优化查询语句
索引分类
- 普通索引：是最基本的索引，它没有任何限制，即一个索引只包含单个列，一个表可以有多个单列索引；建议一张表索引不要超过5个，优先考虑复合索引
- 唯一索引：与前面的普通索引类似，不同的就是：索引列的值必须唯一，但允许有空值。如果是组合索引，则列值的组合必须唯一
- 主键索引：是一种特殊的唯一索引，一个表只能有一个主键，不允许有空值。一般是在建表的时候同时创建主键索引：
- 复合索引：指多个字段上创建的索引，只有在查询条件中使用了创建索引时的第一个字段，索引才会被使用。使用组合索引时遵循最左前缀集合
- 全文索引：主要用来查找文本中的关键字，而不是直接与索引中的值相比较。fulltext索引跟其它索引大不相同，它更像是一个搜索引擎，而不是简单的where语句的参数匹配
索引语法
创建索引：
- 如果是CHAR和VARCHAR类型，length可以小于字段实际长度；
- 如果是BLOB和TEXT类型，必须指定length。
CREATE [UNIQUE] INDEX indexName ON mytable(columnname(length));
' or '
ALTER mytable ADD [UNIQUE] INDEX [indexName] ON(columnname(length));
123
删除索引
DROP INDEX [indexName] ON mytable;
1
查看索引（\G表示将查询到的横向表格纵向输出，方便阅读）
SHOW INDEX FROM table_name\G
使用 ALTER 命令，有四种方式来添加数据表的索引：
ALTER TABLE tbl_name ADD PRIMARY KEY(column_list)：该语句添加一个主键，这意味着索引值必须是唯一的，且不能为NULL。ALTER TABLE tbl_name ADD UNIQUE index_name(column_list)：这条语句创建索引的值必须是唯一的（除了NULL外，NULL可能会出现多次）。ALTER TABLE tbl_name ADD INDEX index_name(column_list)：.添加普通索引，索引值可出现多次。ALTER TABLE tbl_name ADD FULLTEXT index_name(column_list)：该语句指定了索引为FULLTEXT，用于全文索引。
B树索引
Btree 索引搜索过程
【初始化介绍】
- 一颗 b 树， 浅蓝色的块我们称之为一个磁盘块， 可以看到每个磁盘块包含几个数据项（深蓝色所示） 和指针（黄色所示）
- 如磁盘块 1 包含数据项 17 和 35， 包含指针 P1、 P2、 P3
- P1 表示小于 17 的磁盘块， P2 表示在 17 和 35 之间的磁盘块， P3 表示大于 35 的磁盘块
- 真实的数据存在于叶子节点和非叶子节点中
【查找过程】
-
如果要查找数据项 29， 那么首先会把磁盘块 1 由磁盘加载到内存， 此时发生一次 IO， 在内存中用二分查找确定 29在 17 和 35 之间， 锁定磁盘块 1 的 P2 指针， 内存时间因为非常短（相比磁盘的 IO） 可以忽略不计
-
通过磁盘块 1的 P2 指针的磁盘地址把磁盘块 3 由磁盘加载到内存， 发生第二次 IO， 29 在 26 和 30 之间， 锁定磁盘块 3 的 P2 指针
-
通过指针加载磁盘块 8 到内存， 发生第三次 IO， 同时内存中做二分查找找到 29， 结束查询， 总计三次 IO。
B+树索引
B+tree 索引搜索过程
【B+Tree 与 BTree 的区别】
B-树的关键字（数据项）和记录是放在一起的； B+树的非叶子节点中只有关键字和指向下一个节点的索引， 记录只放在叶子节点中。
【B+Tree 与 BTree 的查找过程】
- 在 B 树中， 越靠近根节点的记录查找时间越快， 只要找到关键字即可确定记录的存在； 而 B+ 树中每个记录的查找时间基本是一样的， 都需要从根节点走到叶子节点， 而且在叶子节点中还要再比较关键字。
- 从这个角度看 B 树的性能好像要比 B+ 树好， 而在实际应用中却是 B+ 树的性能要好些。 因为 B+ 树的非叶子节点不存放实际的数据，这样每个节点可容纳的元素个数比 B 树多， 树高比 B 树小， 这样带来的好处是减少磁盘访问次数。
- 尽管 B+ 树找到一个记录所需的比较次数要比 B 树多， 但是一次磁盘访问的时间相当于成百上千次内存比较的时间， 因此实际中B+ 树的性能可能还会好些， 而且 B+树的叶子节点使用指针连接在一起， 方便顺序遍历（范围搜索）， 这也是很多数据库和文件系统使用 B+树的缘故。
【性能提升】
真实的情况是， 3 层的 B+ 树可以表示上百万的数据， 如果上百万的数据查找只需要三次 IO， 性能提高将是巨大的，如果没有索引， 每个数据项都要发生一次 IO， 那么总共需要百万次的 IO， 显然成本非常非常高。
【思考： 为什么说 B+树比 B-树更适合实际应用中操作系统的文件索引和数据库索引？】
- B+树的磁盘读写代价更低：B+树的内部结点并没有指向关键字具体信息的指针。 因此其内部结点相对 B 树更小。 如果把所有同一内部结点的关键字存放在同一盘块中， 那么盘块所能容纳的关键字数量也越多。 一次性读入内存中的需要查找的关键字也就越多。 相对来说 IO 读写次数也就降低了。
- B+树的查询效率更加稳定：由于非终结点并不是最终指向文件内容的结点， 而只是叶子结点中关键字的索引。 所以任何关键字的查找必须走一条从根结点到叶子结点的路。 所有关键字查询的路径长度相同， 导致每一个数据的查询效率相当。
何时要建索引
哪些情况下适合建立索引
- 主键自动建立唯一索引
- 频繁作为查询的条件的字段应该创建索引
- 查询中与其他表关联的字段，外键关系建立索引
- 频繁更新的字段不适合创建索引
- Where 条件里用不到的字段不创建索引
- 单间/组合索引的选择问题，Who？（在高并发下倾向创建组合索引）
- 查询中排序的字段，排序字段若通过索引去访问将大大提高排序的速度
- 查询中统计或者分组字段
哪些情况不要创建索引
- 表记录太少
- 经常增删改的表
- 数据重复且分布平均的表字段，因此应该只为经常查询和经常排序的数据列建立索引。注意，如果某个数据列包含许多重复的内容，为它建立索引就没有太大的实际效果。
分析：
- 假如一个表有10万行记录，有一个字段A只有T和F两种值，且每个值的分布概率大约为50%，那么对这种表A字段建索引一般不会提高数据库的查询速度。
- 索引的选择性是指索引列中不同值的数目与表中记录数的比。如果一个表中有2000条记录，表索引列有1980个不同的值，那么这个索引的选择性就是1980/2000=0.99。
- 一个索引的选择性越接近于1，这个索引的效率就越高。
性能分析
优化概述
MySQL Query Optimizer 的作用
- MySQL 中有专门负责优化SELECT语句的优化器模块，主要功能：通过计算分析系统中收集到的统计信息，为客户端请求的Query提供他认为最优的执行计划（MySQL认为最优的数据检索方式，但不见得是DBA认为是最优的，这部分最耗费时间）
- 当客户端向MySQL 请求一条Query，命令解析器模块完成请求分类，区别出是SELECT并转发给MySQL Query Optimizer时，MySQL Query Optimizer 首先会对整条Query进行优化，处理掉一些常量表达式的预算，直接换算成常量值。并对Query中的查询条件进行简化和转换，如去掉一些无用或显而易见的条件、结构调整等。然后分析 Query中的Hint信息（如果有），看显示Hint信息是否可以完全确定该Query的执行计划。如果没有Hint 或Hint 信息还不足以完全确定执行计划，则会读取所涉及对象的统计信息，根据Query进行写相应的计算分析，然后再得出最后的执行计划。
MySQL 常见瓶颈
- CPU 瓶颈：CPU在饱和的时候一般发生在数据装入在内存或从磁盘上读取数据时候
- IO 瓶颈：磁盘I/O瓶颈发生在装入数据远大于内存容量时
- 服务器硬件的性能瓶颈：top、free、iostat和vmstat来查看系统的性能状态
Explain概述
Explain
是什么？Explain 是查看执行计划
- 使用EXPLAIN关键字可以模拟优化器执行SQL语句，从而知道MySQL是如何处理你的SQL语句的。分析你的查询语句或是结构的性能瓶颈
- 官网地址：https://dev.mysql.com/doc/refman/8.0/en/explain-output.html
-
能干嘛？
- 表的读取顺序（id 字段）
- 数据读取操作的操作类型（select_type 字段）
- 哪些索引可以使用（possible_keys 字段）
- 哪些索引被实际使用（keys 字段）
- 表之间的引用（ref 字段）
- 每张表有多少行被优化器查询（rows 字段）
怎么用？
- Explain + SQL语句
mysql> explain select * from tbl_emp; +----+-------------+---------+------+---------------+------+---------+------+------+-------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+---------+------+---------------+------+---------+------+------+-------+ | 1 | SIMPLE | tbl_emp | ALL | NULL | NULL | NULL | NULL | 8 | NULL | +----+-------------+---------+------+---------------+------+---------+------+------+-------+ 1 row in set (0.00 sec)
Explain详解
id：select查询的序列号，包含一组数字，表示查询中执行select子句或操作表的顺序
id 取值的三种情况：
-
id相同，执行顺序由上至下
-
id不同，如果是子查询，id的序号会递增，id值越大优先级越高，越先被执行
-
id相同不同，同时存在：id如果相同，可以认为是一组，从上往下顺序执行；在所有组中，id值越大，优先级越高，越先执行；衍生=DERIVED
select_type：查询的类型，主要用于区别普通查询、联合查询、子查询等复杂查询
- SIMPLE：简单的select查询，查询中不包含子查询或者UNION
- PRIMARY：查询中若包含任何复杂的子部分，最外层查询则被标记为PRIMARY
- SUBQUERY：在SELECT或者WHERE列表中包含了子查询
- DERIVED：在FROM列表中包含的子查询被标记为DERIVED（衍生）MySQL会递归执行这些子查询，把结果放在临时表里
- UNION：若第二个SELECT出现在UNION之后，则被标记为UNION；若UNION包含在FROM子句的子查询中，外层SELECT将被标记为：DERIVED
- UNION RESULT：从UNION表获取结果的SELECT
table：显示这一行的数据是关于哪张表的
type：访问类型排列，显示查询使用了何种类型
- type显示的是访问类型，是较为重要的一个指标，结果值从最好到最坏依次是：
system>const>eq_ref>ref>fultext>ref_or_null>index_merge>unique_subquery>index_subquery>range>index>ALL - 挑重要的来说：
system>const>eq_ref>ref>range>index>ALL，一般来说，得保证查询至少达到range级别，最好能达到ref。
从最好到最差依次是：system>const>eq_ref>ref>range>index>ALL
- system：表只有一行记录（等于系统表），这是const类型的特例，平时不会出现，这个也可以忽略不计
- const：表示通过索引一次就找到了，const用于比较primary key或者unique索引。因为只匹配一行数据，所以很快。如将主键置于where列表中，MySQL就能将该查询转换为一个常量
- eq_ref：唯一性索引，对于每个索引键，表中只有一条记录与之匹配，常见于主键或唯一索引扫描
- ref：非唯一索引扫描，返回匹配某个单独值的所有行。本质上也是一种索引访问，它返回所有匹配某个单独值的行，然而，它可能会找到多个符合条件的行，所以他应该属于查找和扫描的混合体
- range：只检索给定范围的行，使用一个索引来选择行。key列显示使用了哪个索引一般就是在你的where语句中出现了
between、<、>、in等的查询这种范围扫描索引扫描比全表扫描要好，因为他只需要开始索引的某一点，而结束于另一点，不用扫描全部索引 - index：Full Index Scan，index与ALL区别为index类型只遍历索引树。这通常比ALL快，因为索引文件通常比数据文件小。（也就是说虽然all和index都是读全表，但index是从索引中读取的，而all是从硬盘数据库文件中读的）
- all：FullTable Scan，将遍历全表以找到匹配的行（全表扫描）
- 备注：一般来说，得保证查询只是达到range级别，最好达到ref
possible_keys
- 显示可能应用在这张表中的索引，一个或多个
- 若查询涉及的字段上存在索引，则该索引将被列出，但不一定被查询实际使用
key
- 实际使用的索引，如果为null，则没有使用索引
- 若查询中使用了覆盖索引，则该索引仅出现在key列表中
key_len
- 表示索引中使用的字节数，可通过该列计算查询中使用的索引的长度。在不损失精确性的情况下，长度越短越好
- key_len显示的值为索引最大可能长度，并非实际使用长度，即key_len是根据表定义计算而得，不是通过表内检索出的
ref
显示索引哪一列被使用了，如果可能的话，最好是一个常数（用const表示）。哪些列或常量被用于查找索引列上的值
rows
根据表统计信息及索引选用情况，大致估算出找到所需的记录所需要读取的行数
Extra：包含不适合在其他列中显示但十分重要的额外信息
-
Using filesort（文件排序）：
- MySQL中无法利用索引完成排序操作成为“文件排序”
- 说明mysql会对数据使用一个外部的索引排序，而不是按照表内的索引顺序进行读取
- 出现 Using filesort 不好（九死一生），需要尽快优化 SQL
-
Using temporary（创建临时表）：
- 使用了临时表保存中间结果，MySQL在对查询结果排序时使用临时表。常见于排序 order by 和分组查询 group by
- 出现 Using temporary 超级不好（十死无生），需要立即优化 SQL
-
Using index（覆盖索引）：
- 表示相应的select操作中使用了覆盖索引（Coveing Index），避免访问了表的数据行，效率不错！
- 如果同时出现using where，表明索引被用来执行索引键值的查找
- 如果没有同时出现using where，表明索引用来读取数据而非执行查找动作
- 覆盖索引（Covering Index），也说为索引覆盖
- 理解方式：就是select的数据列只用从索引中就能够取得，不必读取数据行，MySQL可以利用索引返回select列表中的字段，而不必根据索引再次读取数据文件，换句话说查询列要被所建的索引覆盖。
- 注意：如果要使用覆盖索引，一定要注意select列表中只取出需要的列，不可
select \*，因为如果将所有字段一起做索引会导致索引文件过大，查询性能下降。
-
Using where：表明使用了where过滤
-
Using join buffer：表明使用了连接缓存
-
impossible where：where子句的值总是false，不能用来获取任何元组
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
