资讯专栏INFORMATION COLUMN

对一个26万数据MYSQL表的Yii2程序优化实战之二 【开刀数据表】

whataa / 1890人阅读

摘要:在这里我并不打算对其进行所谓的优化,具体原因可以看北哥工兵连引的一篇文章应用的缓存设计模式,如果有一天它真的影响了,我们可以在关联层加一个缓存来解决。

上一节我们对订餐系统后台欢迎页面的统计图表进行了处理,在本节我们将对订单列表和详细订单列表进行优化。

中间穿插个小广告哈,北哥在segmengfault上的讲座下周二开始,主要说yii2和微信支付的那点事,感兴趣的可以去看看 https://segmentfault.com/l/15...

这节我们将涉及到的东西如下

数据表加索引后的对比

下文会设计的表有order_box和order,我先放个图,方便大家了解。

order_box:订单表,里面会有很多子订单order

order:子订单表 每个子订单代表选择了一种菜品

订单列表页

这是个订单列表页,每个订单里面有关联的菜品等,我们先看看优化前的样子,分页为每页10个。

对应action的代码

$query = OrderBox::find()->where(["store_id"=>Yii::$app->admin->identity->store_id])->orderBy(["create_time"=>SORT_DESC]);

// 这里有一些搜索项,对应的数据表字段有(serial_number、bank_number、pay_type)

$dataProvider = new ActiveDataProvider([
    "query" => $query,
    "pagination" => ["pagesize" => 10]
]);

多么简单的逻辑,那先看一看yii2-debug给我们的结果。

从页面分析原因可能出现在两个方面

数据表没有索引

视图层过多的关联导致

既然本章叫做开刀数据表,那我们先给数据表加下索引,先不考虑搜索的情况,我对order_box的store_id和create_time加下索引。

结果未达到预期

为order_box增加索引后并没有减少多少时间。这是为什么那?

重新审视

还记得上一篇(传送门)我们的order_box有8万多数据,而order有26万多数据,再看我们的订单页面。

每个order_box都1对N了很多个order表数据,而order表有26w数据,如果这个关联字段没有索引,就可能导致慢。

果然,现在的order表索引空空如也,我们先为其关联order_box的字段box_id加上索引。

看看yii2-debug的反馈

很高兴我们找到了这个页面的诟病所在,通过对order的box_id加索引将数据库执行时间降到了76毫秒,而之前是3000多毫秒,事实上对于这种数量级的数据,通过数据库索引的添加可以解决大部分性能问题。

但是这还没完事,因为我想尽量减少数据库的检索次数,一点一点来吧,我要先解决订单列表页搜索的优化。

当然我也知道,“索引”是把双刃剑,带来速递提升同会带来损耗,所以这要辩证的看,接下来就会遇到。

当我来测试针对 订单ID、序号、银行号码的时候,是否加索引并没有带来太大影响(起码当前是这样),但是当我对支付方式增加索引的时候,运行时间竟然变慢了一倍。

当然为什么慢了这里将不进行讲解,以后会有专门讲MYSQL高性能索引的文章。

我们只需要记住,对于添加索引,一定要测试,有可能它带来副作用,切记切记。

减少查询次数???

上面说到我想减少数据库查询次数,使用yii2-debug我看到这个页面sql语句的增加来源于Yii2的AR关联行为导致。

在这里我并不打算对其进行所谓的优化,具体原因可以看 北哥工兵连 引的一篇文章《Web应用的缓存设计模式》,如果有一天它真的影响了,我们可以在关联层加一个缓存来解决。

因此虽然60多次看着挺碍眼,但是我决定不做出来,它的存在并没有带来性能过多损耗并且大幅度简化了逻辑。

那么这个页面就这样,我们再总结一下

加索引,加索引,对比着加索引

对于AR关联如果性能影响不大,暂时忽略。

这个页面比较简单,就是一个表的检索加一些AR关联,接下来我要处理订单详情页面,这个页面是order表的列表。

我们先看下页面和yii2-debug的反馈。

连个关联都没有,就是order表的分页,看看结果。

到底问题出在哪里???

就是他们导致的,子查询、sum、group by等等,知道了原因,那就想办法解决吧,好,等待阿北下一篇

对一个26万数据MYSQL表的Yii2程序优化实战之三 【数据表再优化】,给大家讲讲针对子查询、group by以及关联的优化行为。

(完)

本文原创发布于微信公众号 北哥小报 , 严谨的原创技术文,Q群:171277552。

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/48722.html

相关文章

  • 一个26数据MYSQL表的Yii2程序优化实战之一 【去糟粕、加缓存】

    摘要:记住它,一点点来,万物均可优化。下一篇将为你讲解对一个万数据的表程序优化实战真实例子之二开刀数据表完本文原创发布于微信公众号北哥小报严谨的原创技术文,还有一些其他研究。 showImg(https://segmentfault.com/img/bVPBSr?w=1200&h=500); 这是一篇真实案例,并不是理论课,阿北将同步我的整个优化之路,优化之路慢慢长,对大家抛砖引玉已达目的,...

    LiuZh 评论0 收藏0
  • 一个26数据MYSQL表的Yii2程序优化实战之一 【去糟粕、加缓存】

    摘要:记住它,一点点来,万物均可优化。下一篇将为你讲解对一个万数据的表程序优化实战真实例子之二开刀数据表完本文原创发布于微信公众号北哥小报严谨的原创技术文,还有一些其他研究。 showImg(https://segmentfault.com/img/bVPBSr?w=1200&h=500); 这是一篇真实案例,并不是理论课,阿北将同步我的整个优化之路,优化之路慢慢长,对大家抛砖引玉已达目的,...

    Vultr 评论0 收藏0
  • ❤️‍Kettle--老板说:这套生产数据库千、亿级数据量迁移方案,学会就赚了❤️‍(工作学习必备

    ❤️‍您好,我是贾斯汀,这是我写了蛮久的一套工作学习实用的数据库数据迁移实战演练+性能优化方案~❤️‍ ❤️‍也希望看到最后觉得有帮助的小伙伴,在文末或者点击这里,直接跳到文章末尾,关注一下博主哦~❤️‍ 北海侨港(图) 【实战前言】 (1)不管你是学生,还是已经工作了的小伙伴,可能你在过去、现在或者未来,会遇到这样的问题,公司/项目用的是Oracle/DB2/MySQL等关系型数据库,因公...

    james 评论0 收藏0
  • PHP面试之二:高并发与大数据

    摘要:三态分别是就绪运行阻塞进程的五态模型在三态的基础上发展而来新建态运行态终止态就绪态等待态线程称之为轻量级的进程,程序执行流的最小单元。一个进程下有多个线程来完成不同的工作称之为多线程。 web资源防盗链 盗链是什么? 为什么要防? 在自己页面上显示一些不是自己服务器的资源(图片、音频、视频、css、js等)由于别人盗链你的资源会加重你的服务器负担,所以我们需要防止可能会影响统计 防盗链...

    Ashin 评论0 收藏0
  • 数据库收集 - 收藏集 - 掘金

    摘要:前言在使用加载数据数据库常见的优化操作后端掘金一索引将放第一位,不用说,这种优化方式我们一直都在悄悄使用,那便是主键索引。 Redis 内存压缩实战 - 后端 - 掘金在讨论Redis内存压缩的时候,我们需要了解一下几个Redis的相关知识。 压缩列表 ziplist Redis的ziplist是用一段连续的内存来存储列表数据的一个数据结构,它的结构示例如下图 zlbytes: 记录整...

    Little_XM 评论0 收藏0

发表评论

0条评论

whataa

|高级讲师

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<