php性能优化之不要在for循环中操作DB

目录
  • 前言
  • 场景说明
  • 举例说明
  • 进一步优化
  • 性能对比

前言

如何提高程序运行速度,减轻服务器压力是服务端开发必须面对的一个问题。

简单且朴素的原则:不要在for循环中操作DB,包括关系型数据库和NoSql。

我们应该根据自己的业务场景,在for循环之前批量拿到数据,用尽量少的sql查询批量查到结果。 在for循环中进行数据的匹配组装。

场景说明

  • 业务在多个情景下需要获得用户的详细信息,有点可以通过查询用户表直接获取到,有的需要查询关联关系表获取到,有的只保存了关联的id,并没有单独创建关联关系表,需要单独写获取函数取值。
  • 既然多个场景下需要调用,那么封装成一个公共方法,让多个场景统一调用公共方法是基本的优化思路。
  • 上面提到了复杂的存取值关系,我们需要分析一下,哪些操作是耗时的,耗时的操作如何优化,能否减少sql查询的次数。

举例说明

  • 下面的代码示例,我们封装了 CommonRender 的类,所有可以统一输出的方法都在这里
  • 下面代码标注了优化之前优化之后
  • 优化之前:在每次查询都需要根据保存的id,去数据库查询;如果列表页每次返回30条数据,那这部分就需要30次sql查询。
  • 优化之后:采用的是提前批量取值,又写了一个函数 _renderHobby ,只需要1次sql。
  • 这样就极大的减少了sql查询,提高了程序响应的速度。
<?php
namespace App\Render;
.
.
.
class CommonRender extends BaseRender
{
    public static function renderUserinfo($data, $hobbyInfo = [])
    {
        if (!is_array($data)) {
            return [];
        }
        $ret = [
            'uid' => !isset($data['id']) ? 0 : $data['id'],
            'userid' => !isset($data['userid']) ? '' : $data['userid'],
            'username' => !isset($data['username']) ? '' : $data['username'],
            'usericon' => !isset($data['usericon']) ? [] : $data['usericon'],
            .
            .
            .
//优化之前
//          'hobby' => !isset($data['hobby']) ? [] : HobbyInfo::getByIds($data['hobby']),
//优化之后
            'hobby' => !isset($data['hobby']) ? [] : self::_renderHobby($data['hobby'], $hobbyInfo),
            .
            .
            .
        if (!empty($ret['birth'])) {
            $ret['zodiacSign'] = Utility::getZodiacSign($ret['birth']);
        } else {
            $ret['zodiacSign'] = '';
        }
        return $ret;
    }
    protected static function _renderHobby($userHobby, $hobbyInfo)
    {
        $ret = [];
        if ($userHobby) {
            $userHobbyIds = explode(',', $userHobby);
            foreach ($userHobbyIds as $key => $userHobbyId) {
                $ret[$key] = $hobbyInfo[$userHobbyId];
            }
        }
        return $ret;
    }
    //用户列表卡片常用字段
    public static function renderListCardUserinfo($data)
    {
        .
        .
        .
    }
}

进一步优化

上面的代码已经优化了性能,但是还不够优雅。

获取单用户信息场景比较多,比如编辑,登录,查看单人信息等,这种情况下我还每次都提前批量查询吗?这样的话需要改造的地方太多了。

下面做进一步优化:

在render方法内部封装了一层,如果外部没有传入或传入空数组,自己再查询db获得一次需要的数据源。

<?php
namespace App\Render;
.
.
.
class CommonRender extends BaseRender
{
    public static function renderUserinfo($data, $hobbyInfo = [])
    {
        //区别在这里:批量查询外部传入,减少sql查询次数; 单次查询在render内查一次
        $hobbyInfo = !empty($hobbyInfo) ? $hobbyInfo : HobbyInfo::getAllInfo();
        if (!is_array($data)) {
            return [];
        }
        $ret = [
            'uid' => !isset($data['id']) ? 0 : $data['id'],
            'userid' => !isset($data['userid']) ? '' : $data['userid'],
            'username' => !isset($data['username']) ? '' : $data['username'],
            'usericon' => !isset($data['usericon']) ? [] : $data['usericon'],
            .
            .
            .
//优化之前
//          'hobby' => !isset($data['hobby']) ? [] : HobbyInfo::getByIds($data['hobby']),
//优化之后
            'hobby' => !isset($data['hobby']) ? [] : self::_renderHobby($data['hobby'], $hobbyInfo),
            .
            .
            .
        if (!empty($ret['birth'])) {
            $ret['zodiacSign'] = Utility::getZodiacSign($ret['birth']);
        } else {
            $ret['zodiacSign'] = '';
        }
        return $ret;
    }
    protected static function _renderHobby($userHobby, $hobbyInfo)
    {
        $ret = [];
        if ($userHobby) {
            $userHobbyIds = explode(',', $userHobby);
            foreach ($userHobbyIds as $key => $userHobbyId) {
                $ret[$key] = $hobbyInfo[$userHobbyId];
            }
        }
        return $ret;
    }
    //用户列表卡片常用字段
    public static function renderListCardUserinfo($data)
    {
        .
        .
        .
    }
}

这样,那些获得单个用户资料的方法就不需要修改了。

    //编辑用户资料
    public function editUserInfo(Request $request)
    {
        $userInfo = UserInfo::editUserById($this->_userid, $request);
        return [
            'user' =>
                CommonRender::renderUserinfo($userInfo)
                + UserInfo::formatCoverAndPickedFootprint($userInfo)
        ];
    }

性能对比

批量获得用户信息对比:性能提升立竿见影。

  • 比如每次取30个用户数据,之前获得爱好,职业,期望部分要查询30次db。
  • 优化之后只需要查询3次db。
    public static function getBatchUserIntro($userid, $userList)
    {
        $retData = [];
        if (empty($userList)) {
            return $retData;
        }
        .
        .
        .
        //批量获得爱好、职业、期望遇到 在foreach中计算取值,不重复请求DB取值
        $hobbyInfo = HobbyInfo::getAllInfo();
        $professionInfo = ProfessionInfo::getAllInfo();
        $expectInfo = ExpectInfo::getAllInfo();
        foreach ($batchUserInfo as $item) {
            $retData[$item['userid']] = array_merge(
                    ['wxnumber' => Utility::maskWxnumber($item['wxnumber'], $batchExchangeStatus[$item['userid']] == UserUserWeixinExchange::TYPE_TRUE)]
                    + CommonRender::renderUserinfo($item, $hobbyInfo, $professionInfo, $expectInfo);
        }
        .
        .
        .
        return $retData;
    }

注意,为了行文紧凑,代码段中省略了和文章无关的代码,用竖着的三个.省略。

以上就是php性能优化之不要在for循环中操作DB的详细内容,更多关于php性能优化for循环DB操作的资料请关注我们其它相关文章!

时间: 2022-06-10

PHP开发注意事项总结

1.使用内嵌的HTML代码,而不是PHP的echo语句. 因为PHP是一门嵌入式Web编程语言,可以将HTML代码和PHP代码相互嵌入.但是很多程序员担心在HTML代码中过多的使用""嵌入PHP代码会多次调用PHP解释器,从而降低了PHP代码的运行速度,所以宁愿使用PHP的echo语句来输出HTML代码,而不直接使用HTML代码.但事实却恰恰相反.每一个PHP页面只调用一次PHP解释器来解释所有的PHP代码,所以,只在需要时才嵌入PHP代码,而大多数的时候直接使用HTML代码输入结果,

PHP+swoole+linux实现系统监控和性能优化操作示例

本文实例讲述了PHP+swoole+linux实现系统监控和性能优化操作.分享给大家供大家参考,具体如下: 服务器监控 端口监控php运行shell脚本 class Server { const PORT = 8811; /** * 获取端口指定端口信息;如果在运行返回1:否则返回0: */ public function port() { $shell = "netstat -anp 2>/dev/null | grep ". self::PORT . " | gre

PHP-FPM实现性能优化

简介: PHP-FPM 是一个 PHP FastCGI 管理器,一般 Nginx 上面跑 PHP 程序都会将 PHP 程序丢给 PHP-FPM 来解析.好了,就这样! PHP 5.4 开始集成了 PHP-FPM ,也就是说编译 PHP 时,只要 --enable-fpm 就装好了 PHP-FPM . 一.安装 PHP-FPM shell > ./configure --prefix=/usr/local/php \ --with-config-file-path=/usr/local/php -

PHP中你可能忽略的性能优化利器:生成器

前言 如果是做Python或者其他语言的小伙伴,对于生成器应该不陌生.但很多PHP开发者或许都不知道生成器这个功能,可能是因为生成器是PHP 5.5.0才引入的功能,也可以是生成器作用不是很明显.但是,生成器功能的确非常有用. 什么情况之下,会遇到PHP性能问题? 1:PHP语法使用不恰当. 2:使用PHP语言做了它不擅长的事情. 3:使用PHP语言连接的服务不给力. 4:PHP自身的短板(PHP自身做不了的事情). 5:我们也不知道的问题?(去探索.分析找到解决办法,提升开发境界). 优点 直

PHP性能优化大全(php.ini)

第一章  针对系统调用过多的优化 我这次的优化针对syscall调用过多的问题,所以使用strace跟踪apache进行分析. 1.  apache2ctl -X & 使用-X(debug)参数启动httpd进程,这个时候只启动1个httpd进程 2. ps -ef | grep httpd 找到需要strace的pid 3. strace -p $PID -o /tmp/strace.log 发送一个http请求到httpd,就能看到strace信息了.   一.include_path问题

php之性能优化案例

php是一个很流行的脚本语言,现在很多公司(新浪.优酷.百度.搜狐.淘宝等等)在使用这种语言进行网站开发.我的这篇文章,我只是希望能够提高你的php脚本性能.请记住你的php脚本性能,很多时候依赖于你的php版本.你的web server环境和你的代码的复杂度. 优化你代码中的瓶颈 Hoare曾经说过"过早优化是一切不幸的根源".当你想要让你的网站更快运转的时候,你才应该去做优化的事情.当你要改变你代码之前,你需要做的事是什么原因引起了系统缓慢?你可以通过以下指导和其他方式优化你的ph

Mysql性能优化案例研究-覆盖索引和SQL_NO_CACHE

场景 产品中有一张图片表pics,数据量将近100万条,有一条相关的查询语句,由于执行频次较高,想针对此语句进行优化 表结构很简单,主要字段: 复制代码 代码如下: user_id 用户ID picname 图片名称 smallimg 小图名称 一个用户会有多条图片记录,现在有一个根据user_id建立的索引:uid,查询语句也很简单:取得某用户的图片集合: 复制代码 代码如下: select picname, smallimg from pics where user_id = xxx; 优化

Mysql性能优化案例 - 覆盖索引分享

场景 产品中有一张图片表,数据量将近100万条,有一条相关的查询语句,由于执行频次较高,想针对此语句进行优化 表结构很简单,主要字段: 复制代码 代码如下: user_id 用户ID picname 图片名称 smallimg 小图名称 一个用户会有多条图片记录 现在有一个根据user_id建立的索引:uid 查询语句也很简单:取得某用户的图片集合 复制代码 代码如下: select picname, smallimg from pics where user_id = xxx; 优化前 执行查

ASP.NET性能优化小结(ASP.NET&amp;C#)

ASP.NET: 一.返回多个数据集 检查你的访问数据库的代码,看是否存在着要返回多次的请求.每次往返降低了你的应用程序的每秒能够响应请求的次数.通过在单个数据库请求中返回多个结果集,可以减少与数据库通信的时间,使你的系统具有扩展性,也可以减少数据库服务器响应请求的工作量. 如果用动态的SQL语句来返回多个数据集,那用存储过程来替代动态的SQL语句会更好些.是否把业务逻辑写到存储过程中,这个有点争议.但是我认为,把业务逻辑写到存储过程里面可以限制返回结果集的大小,减小网络数据的流量,在逻辑层也不

数据库访问性能优化

在网上有很多文章介绍数据库优化知识,但是大部份文章只是对某个一个方面进行说明,而对于我们程序员来说这种介绍并不能很好的掌握优化知识,因为很多介绍只是对一些特定的场景优化的,所以反而有时会产生误导或让程序员感觉不明白其中的奥妙而对数据库优化感觉很神秘. 很多程序员总是问如何学习数据库优化,有没有好的教材之类的问题.在书店也看到了许多数据库优化的专业书籍,但是感觉更多是面向DBA或者是PL/SQL开发方面的知识,个人感觉不太适合普通程序员.而要想做到数据库优化的高手,不是花几周,几个月就能达到的,这

SQL性能优化之定位网络性能问题的方法(DEMO)

最近项目组同事跟我说遇到一个SQL性能问题,他说全表只有69条记录,客户端执行耗费了两分多钟,很不科学.我帮了分析出了原因并得到解决.下面小编安装类似表结构,构造了一个案例,测试截图如下所示: 这个表有13800KB(也就是13M多大小),因为该表将图片保存到数据库(Item_Photo字段为iamge类型),这个是历史原因,暂且不喷这种的设计.看来这个SQL执行时间长的性能问题不在于IO和SQL本身执行计划是否有问题,而是在网络数据传时间上(服务器与客户端位于异地,两地专线带宽6M,不过很多应

Mysql数据库性能优化三(分表、增量备份、还原)

接上篇Mysql数据库性能优化二 对表进行水平划分     如果一个表的记录数太多了,比如上千万条,而且需要经常检索,那么我们就有必要化整为零了.如果我拆成100个表,那么每个表只有10万条记录.当然这需要数据在逻辑上可以划分.一个好的划分依据,有利于程序的简单实现,也可以充分利用水平分表的优势.比如系统界面上只提供按月查询的功能,那么把表按月拆分成12个,每个查询只查询一个表就够了.如果非要按照地域来分,即使把表拆的再小,查询还是要联合所有表来查,还不如不拆了.所以一个好的拆分依据是 最重要的

MYSQL性能优化分享(分库分表)

1.分库分表 很明显,一个主表(也就是很重要的表,例如用户表)无限制的增长势必严重影响性能,分库与分表是一个很不错的解决途径,也就是性能优化途径,现在的案例是我们有一个1000多万条记录的用户表members,查询起来非常之慢,同事的做法是将其散列到100个表中,分别从members0到members99,然后根据mid分发记录到这些表中,牛逼的代码大概是这样子: 复制代码 代码如下: <?php for($i=0;$i< 100; $i++ ){ //echo "CREATE TA

浅谈react性能优化的方法

React性能优化思路 软件的性能优化思路就像生活中去看病,大致是这样的: 使用工具来分析性能瓶颈(找病根) 尝试使用优化技巧解决这些问题(服药) 使用工具测试性能是否确实有提升(疗效确认) 初识react只是为了尽快完成项目,后期进行代码审查时候发现有很多地方需要优化,因此做了个小结. Code Splitting shouldComponentUpdate避免重复渲染 使用不可突变数据结构 组件尽可能的进行拆分.解耦 列表类组件优化 bind函数优化 不要滥用props ReactDOMSe

Vue.js 无限滚动列表性能优化方案

问题 大家都知道,Web 页面修改 DOM 是开销较大的操作,相比其他操作要慢很多.这是为什么呢?因为每次 DOM 修改,浏览器往往需要重新计算元素布局,再重新渲染.也就是所谓的重排(reflow)和重绘(repaint).尤其是在页面包含大量元素和复杂布局的情况下,性能会受到影响.那对用户有什么实际的影响呢? 一个常见的场景是大数据量的列表渲染.通常表现为可无限滚动的无序列表或者表格,当数据很多时,页面会出现明显的滚动卡顿,严重影响了用户体验.怎么解决呢? 解决方案 既然问题的根源是 DOM

Go程序性能优化及pprof使用方法详解

Go 程序的性能优化及 pprof 的使用 程序的性能优化无非就是对程序占用资源的优化.对于服务器而言,最重要的两项资源莫过于 CPU 和内存.性能优化,就是在对于不影响程序数据处理能力的情况下,我们通常要求程序的 CPU 的内存占用尽量低.反过来说,也就是当程序 CPU 和内存占用不变的情况下,尽量地提高程序的数据处理能力或者说是吞吐量. Go 的原生工具链中提供了非常多丰富的工具供开发者使用,其中包括 pprof. 对于 pprof 的使用要分成下面两部分来说. Web 程序使用 pprof