合肥网站建设百家号,wordpress 页面与目录,应用商店aso优化,新手学网络运营要多久概述 好久不见了#xff0c;近期一直在忙项目的事#xff0c;才有时间写博客#xff0c;近期频繁出现sql问题#xff0c;今天正好不忙咱们看看千万级别的表到底该如何优化sql。
案例 近期有个小伙伴生产环境收到了告警#xff0c;有个6千万的日志表#xff0c;查询耗时大…概述 好久不见了近期一直在忙项目的事才有时间写博客近期频繁出现sql问题今天正好不忙咱们看看千万级别的表到底该如何优化sql。
案例 近期有个小伙伴生产环境收到了告警有个6千万的日志表查询耗时大概120秒之前都好好的条件也很简单操作人和被操作人我们查看sql的执行计划发现它走的主键索引operatorName和userName建立了联合索引按说应该走这个索引的呀。 sql 如下条件很简单。
SELECT * from recover_log where operatorName and userName ORDER BY id LIMIT 10 我们看下他的执行计划
mysql EXPLAIN SELECT * from recover_log where operatorName and userName ORDER BY id LIMIT 10;
---------------------------------------------------------------------------------------------------------------------
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
---------------------------------------------------------------------------------------------------------------------
| 1 | SIMPLE | recover_log | NULL | index | NULL | PRIMARY | 8 | NULL | 10 | 1 | Using where |
---------------------------------------------------------------------------------------------------------------------
1 row in set 上面的执行计划中直接采用的主键索引那为什么这么慢呢按说应该用到联合索引的呀我们通过force index强制走联合索引后sql耗时20ms。 其实这个问题的本质是mysql发现数据即便走联合索引数据也会很多而且查询的列有的必须再次回表查询导致直接放弃了联合索引走了主键索引而恰巧呢条件中的数据并非真实存在导致对整个表进行了扫描。 可能有的同学不怎么看执行计划我们简单过一下重点关注这几个字段 type possible_keys key extra 。 type有这么几个值 eq_ref:唯一性索引扫描对于每个索引键表中只有一条记录与之匹配 const: 类似于PRIMARY 只匹配到了一行 system: 表中只有一行记录 index: 遍历了整棵索引树 ref: 非唯一性索引扫描返回匹配某个单独值的所有行 ALL: 对全表进行了扫描性能最慢range: 对索引数进行了范围扫描
possible_keys字段是该条sql在执行中可能用到的索引。
key字段是该条sql执行中真正用的索引。
extra这个字段是一些附加信息但是也很重要常见有以下几种值 Using index使用索引覆盖情况也就是说索引中的数据直接返回的。Using index condition发生了索引下推的情况也就是回表操作如果符合的数据量不大还好如果量很大会造成大量的回表操作导致sql耗时严重。Using filesort可能在磁盘文件中进行了排序或内存中进行的排序性能也是很慢尽可能不让extra出现此值。Using where全表扫描的时候或者用索引扫描的时候通过where条件返回了部分数据。Using temporary用临时表保存结果一般GROUP BY 操作会出现此值性能也较慢比如
mysql explain select * from sign_job_info_copy1 group by mssp_id;
---------------------------------------------------------------------------------------------------------------------------
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
---------------------------------------------------------------------------------------------------------------------------
| 1 | SIMPLE | sign_job_info_copy1 | ALL | NULL | NULL | NULL | NULL | 12305505 | Using temporary; Using filesort |
---------------------------------------------------------------------------------------------------------------------------
1 row in set (0.01 sec)
总结 mysql的执行计划有时候不一定是最优的我们还需要利用explain多多了解执行计划根据执行情况分析出sql的执行慢的原因。 关注执行计划的时候不能只看某个值应该多个字段联合起来分析sql好了这期就先简单到这了。 MYSQL系列经典文章 MYSQl深入探索系列一 redo log MYSQl深入探索系列二 undo log MYSQl深入探索系列三 MVCC机制 MYSQl深入探索系列四 服务端优化 MYSQl深入探索系列五 buffer_pool
