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

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

中间穿插个小广告哈，北哥在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。