【MySQL】《狂飙》电视剧火了,如果程序一直狂飙,扛不住了,怎么办呢?
程序如果狂飙了怎么办呢?
《狂飙》电视剧你看了吗?
咖啡干嚼不加糖,我是建工高启强。
手拿冻鱼追一路,我叫启盛你记住。
鱼摊卖鱼开箱货,杀人还得陈金默。
孟钰启兰把我亲,只玩不处叫安欣。
先亲程程后摸腿,我是莽村李宏伟。
AD钙奶来上香, 京海大佬叫徐江。
老公被埋不知情,我是大嫂陈书婷。
脚踩五菱没刹车,记住我是有田哥。
放贷不还就见红,我是刀哥唐小龙。
特产一箱接一箱,我是区长龚开疆。
金丝眼镜真斩男,我是御姐高启兰。
早饭喝粥不放糖,我是省委高玉良。
师父牺牲我撒谎,我的名字叫李响。
一路狂飙到凌晨,我是少爷高晓晨。
交警缉毒带管电,我的名字叫杨健。
做局从来不露面,冬哥安排秘书见。
具体的可以看电视剧哈,强哥这个人物张颂文演的可以的。你觉得呢?
程序“狂飙”,你担心吗?
那回到项目程序里面,如果你负责写的项目程序一直狂飙的话,怕不怕,慌不慌。
是不是要想办法解决问题,不让程序挂掉。避免问题出现,控制住成本,不让程序崩溃。
这篇文章就写一下基于MySQL的方面的性能优化处理方法。掌握了MySQL性能调优总能解决一部分问题吧。
性能优化步骤
适合创建索引的情况
- 主键自动建立唯一索引;
- 频繁作为查询条件的字段应该创建索引;
- 查询中与其它表关联的字段,外键关系建立索引;
- 单键/组合索引的选择问题, 组合索引性价比更高;
- 查询中排序的字段,排序字段若通过索引去访问将大大提高排序速度;
- 查询中统计或者分组字段。
不适合创建索引的情况
- 表记录太少;
- 经常增删改的表或者字段;
- Where 条件里用不到的字段不创建索引;
- 过滤性不好的不适合建索引。
Explain 性能分析
使用 EXPLAIN 关键字可以模拟优化器执行 SQL 查询语句,从而知道 MySQL 是如何处理你的 SQL 语句的。
分析查询语句或是表结构的性能瓶颈。
用法: Explain +SQL 语句。
- 执行代码如下,没有where条件
EXPLAIN SELECT * from t_im_contacts
Explain 执行后返回的信息
以上所有结果列说明如下:
参数 | 说明 |
---|---|
id | 选择标识符,id 越大优先级越高,越先被执行;select 查询的序列号,包含一组数字,表示查询中执行 select 子句或操作表的顺序。 |
select_type | 表示查询的类型,主要是用于区别普通查询、联合查询、子查询等的复杂查询 |
table | 输出结果集的表 |
partitions | 匹配的分区 |
type | 表示表的连接类型,类型有很多单独说明下 |
possible_keys | 表示查询时,可能使用的索引 |
key | 表示实际使用的索引 |
key_len | 索引字段的长度 |
ref | 列与索引的比较 |
rows | 大概估算的行数 |
filtered | 按表条件过滤的行百分比 |
Extra | 执行情况的描述和说明 |
id说明
id 相同,执行顺序由上至下
id 不同,如果是子查询,id 的序号会递增,id 值越大优先级越高,越先被执行
id 如果相同,可以认为是一组,从上往下顺序执行;在所有组中,id 值越大,优先级越高,越先执行衍生 = DERIVED
关注点: id 号每个号码,表示一趟独立的查询。一个 sql 的查询趟数越少越好。
select_type 说明
type字段说明
最重要的就是 type 字段,type 值类型如下:
- all — 扫描全表数据;
- index — 遍历索引;
- range — 索引范围查找;
- index_subquery — 在子查询中使用 ref;
- unique_subquery — 在子查询中使用 eq_ref;
- ref_or_null — 对 null 进行索引的优化的 ref;
- fulltext — 使用全文索引;
- ref — 使用非唯一索引查找数据;
- eq_ref — 在 join 查询中使用主键或唯一索引关联;
- const — 将一个主键放置到 where 后面作为条件查询, MySQL 优化器就能把这次查询优化转化为一个常量,如何转化以及何时转化,这个取决于优化器,这个比 eq_ref 效率高一点。
Extra说明一下
- 出现 null
表示查询的列未被索引覆盖,且where筛选条件是索引的前导列,这意味着用到了索引,但是部分字段未被索引覆盖,必须通过“回表查询”来实现,性能不是很好。
- Using index condition
表示查询条件中虽然出现了索引列,但是有部分条件无法使用索引,会根据能用索引的条件先搜索一遍再匹配无法使用索引的条件。
- Using index
使用索引,Using index 代表表示相应的 select 操作中使用了覆盖索引(Covering Index),避免访问了表的数据行,效率不错! 如果同时出现 using where,表明索引被用来执行索引键值的查找;如果没有同时出现 using where,表明索引只是 用来读取数据而非利用索引执行查找
- Using where 单独出现
表示当前查询的字段不能被索引覆盖,所以可能会产生回表,效率略低
- Using where,Using index
表示查询的列被索引覆盖,且where筛选条件是索引列前导列的一个范围,或者是索引列的非前导列。 效率比较高
- Using filesort
这种情况是在使用 order by 关键字的时候,如果待排序的内容无法通过索引直接直接进行排序,mysql就有可能进行文件排序。但是由于查询次数过多的话,对于排序的效率还是有一定的影响的。
所以,根据自己的情况进行优化改进即可。你有好的建议欢迎评论区交流讨论。
让自己的程序平稳的运行。
写到最后,一直在技术路上前行…
昨天,删去;今天,争取;明天,努力。
来源地址:https://blog.csdn.net/leng_yong/article/details/128853450
免责声明:
① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。
② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341