对一个26万数据MYSQL表的Yii2程序优化实战之二 【开刀数据表】
上一节咱们对订餐系统后台欢迎页面的统计图表进行了处理，在本节咱们将对订单列表和详细订单列表进行优化。php
这节咱们将涉及到的东西以下html
- 数据表加索引后的对比
下文会设计的表有order_box和order，我先放个图，方便你们了解。sql
- 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加下索引。yii2
结果未达到预期app
为order_box增长索引后并无减小多少时间。这是为何那？yii
从新审视
还记得上一篇（传送门）咱们的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。