性能优化反思:不要在for循环中操作DB 进阶版

简介: 我们允许用户选择职业,系统预制了一批职业标签;又开放了自定义职业标签的功能,不限制自定义标签的次数。允许用户编辑资料时选择2个职业标签。

场景说明


  1. 我们允许用户选择职业,系统预制了一批职业标签;又开放了自定义职业标签的功能,不限制自定义标签的次数。允许用户编辑资料时选择2个职业标签。
  2. 发现用户自定义的职业真的五花八门,随着业务增长,数量级越来越大;比如目前职业标签是2千个,以后可能有2万个,甚至20万个。
  3. 这种情况下,我们上一篇提到的在for循环之前批量查询全量数据,在for循环中用自定义函数匹配,避免在for循环中操作DB的方式命中率太低了,造成了极大的浪费。
  4. 比如:每个列表返回30个用户信息,每个用户选择了2个职业标签,最大标签数量是60;而我全量查到的职业标签数量是2千,命中率只有3%;如果职业标签达到2万个,命中率就只有0.3%了。


解题思路


  1. 首先,在for循环中不操作DB,这个大原则不变
  2. 上述问题的核心是命中率太低,就是全量查了很多用不到的数据
  3. 解决思路就是只批量查询命中的标签数据:
  1. 取到30个用户在user表中保存的职业id
  2. 30个用户的id去重后重组
  3. 在职业表通过whereIn查询匹配的职业标签
  4. 其他逻辑不变,替换的只是数据源:之前的数据源是全量数据,优化后的数据源是精准命中的数据。



代码示例:


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


  1. 核心代码:抽取 renderUserInfo ,统一输出用户信息,这个函数在for循环中调用,获得数据源在for循环之前。


<?php
namespace App\Render;
.
.
.
class CommonRender extends BaseRender
{
    public static function renderUserinfo($data, $hobbyInfo = [],$professionInfo = [])
    {
        $hobbyInfo = !empty($hobbyInfo) ? $hobbyInfo : HobbyInfo::getAllInfo();
        //特殊处理,因为职业用户可以自定义 数字一直增长 不全量查数据;$professionInfo为空时不是批量查询,只查单条记录
        $professionInfo = !empty($professionInfo) ? $professionInfo : (isset($data['profession']) ? ProfessionInfo::getByIds($data['profession']) : []);
        if (!is_array($data)) {
            return [];
        }
        $ret = [
            .
            .
            .
//优化之前
//          'hobby' => !isset($data['hobby']) ? [] : HobbyInfo::getByIds($data['hobby']),
//          'profession' => !isset($data['profession']) ? [] : ProfessionInfo::getByIds($data['profession']),
//优化之后
            'hobby' => !isset($data['hobby']) ? [] : self::_renderHobby($data['hobby'], $hobbyInfo),
            'profession' => !isset($data['profession']) ? [] : self::_renderProfession($data['profession'], $professionInfo),
            .
            .
            .
        return $ret;
    }
}


  1. isset() 判断,避免传入的数据不存在,提示数组越界。


我还整理了一篇 如何避免数组下标越界 ,有兴趣可以阅读一下。


protected static function _renderProfession($userProfession, $professionInfo)
{
    $ret = [];
    if ($userProfession) {
        $userProfessionIds = explode(',', $userProfession);
        foreach ($userProfessionIds as $key => $userProfessionId) {
            if (isset($professionInfo[$userProfessionId])) {
                $ret[$key] = $professionInfo[$userProfessionId];
            }
        }
    }
    return $ret;
}


  1. 调用 commonRender() 的代码,即展示数据源是怎么来的。


public static function getBatchUserIntro($userid, $userList)
{
    $retData = [];
    if (empty($userList)) {
        return $retData;
    }
    .
    .
    .
    $hobbyInfo = HobbyInfo::getAllInfo();
    //按需批量查职业,不全量查询职业
    $professionIds = array_column($batchUserInfo, 'profession');
    $professionIds = implode(',', $professionIds);
    $professionIds = array_unique(explode(',', $professionIds));
    $professionInfo = ProfessionInfo::batchGetByIds($professionIds);
    foreach ($batchUserInfo as $item) {
        $retData[$item['userid']] = CommonRender::renderUserinfo($item, $hobbyInfo, $professionInfo, $expectInfo);
    }
    return $retData;
}


  1. 封装的工具方法,通过id数组批量获得数据,做了特殊判断,兼容值为空的情况。


public static function batchGetByIds($ids = [])
{
    //兼容职业为空的情况
    foreach ($ids as $key => $id) {
        if (empty($id)) {
            unset($ids[$key]);
        }
    }
    if (empty($ids)) {
        return [];
    }
    return self::query()->selectRaw('id,name,pid')
        ->whereIn('id', $ids)
        ->get()
        ->keyBy('id')
        ->toArray();
}


核心代码就是上述4部分


性能对比


以此举例:每次列表返回30个用户信息,每个用户选择了2个职业标签,最大标签数量是60;

优化之前:全量查到的职业标签数量为2千,命中率只有3%;如果职业标签达到2万个,命中率就只有0.3%了。

优化之后:全量查到的职业标签数量为2千,命中率为100%;如果职业标签达到2万个,命中率仍然为100%。


相关文章
|
28天前
|
SQL 存储 关系型数据库
一文搞懂SQL优化——如何高效添加数据
**SQL优化关键点:** 1. **批量插入**提高效率,一次性建议不超过500条。 2. **手动事务**减少开销,多条插入语句用一个事务。 3. **主键顺序插入**避免页分裂,提升性能。 4. **使用`LOAD DATA INFILE`**大批量导入快速。 5. **避免主键乱序**,减少不必要的磁盘操作。 6. **选择合适主键类型**,避免UUID或长主键导致的性能问题。 7. **避免主键修改**,保持索引稳定。 这些技巧能优化数据库操作,提升系统性能。
226 4
一文搞懂SQL优化——如何高效添加数据
|
4月前
|
存储 SQL 关系型数据库
谈谈SQL的优化经验
谈谈SQL的优化经验
|
9月前
|
SQL 关系型数据库 MySQL
【项目实战典型案例】02.SQL语句优化
【项目实战典型案例】02.SQL语句优化
|
SQL 缓存 关系型数据库
【MySQL技术之旅】(6)一直都倾向于优化查询,这次学习一下优化Insert插入语句
【MySQL技术之旅】(6)一直都倾向于优化查询,这次学习一下优化Insert插入语句
136 0
|
SQL NoSQL 关系型数据库
性能优化反思:不要在for循环中操作DB
我们应该根据自己的业务场景,在for循环之前批量拿到数据,用尽量少的sql查询批量查到结果。 在for循环中进行数据的匹配组装
128 0
|
程序员
性能优化反思:减少DB查询,合理使用成员变量
高内聚,低耦合是非常深入人心的设计思想,在做到高内聚低耦合的同时,我们也要考虑到值传递的问题:要避免在抽取函数,封装代码时不合理的值传递,避免在多个函数内部重复查询相同的DB
|
SQL 存储 数据库
SQL基础【二十、索引】(超细致版本,前理论,后实践,应对sql面试绰绰有余)(一)
SQL基础【二十、索引】(超细致版本,前理论,后实践,应对sql面试绰绰有余)(一)
110 0
SQL基础【二十、索引】(超细致版本,前理论,后实践,应对sql面试绰绰有余)(一)
|
SQL 索引
SQL基础【二十、索引】(超细致版本,前理论,后实践,应对sql面试绰绰有余)(三)
SQL基础【二十、索引】(超细致版本,前理论,后实践,应对sql面试绰绰有余)(三)
111 0
SQL基础【二十、索引】(超细致版本,前理论,后实践,应对sql面试绰绰有余)(三)
|
SQL 存储 数据库
SQL基础【二十、索引】(超细致版本,前理论,后实践,应对sql面试绰绰有余)(四)
SQL基础【二十、索引】(超细致版本,前理论,后实践,应对sql面试绰绰有余)(四)
121 0
SQL基础【二十、索引】(超细致版本,前理论,后实践,应对sql面试绰绰有余)(四)
|
SQL 数据库 索引
SQL基础【二十、索引】(超细致版本,前理论,后实践,应对sql面试绰绰有余)(五)
SQL基础【二十、索引】(超细致版本,前理论,后实践,应对sql面试绰绰有余)(五)
111 0
SQL基础【二十、索引】(超细致版本,前理论,后实践,应对sql面试绰绰有余)(五)