查询接口怎么这么慢该如何优化（1）

已于 2024-08-23 20:39:15 修改
阅读量172 收藏 1
点赞数 2
分类专栏： 问题集 文章标签： 数据库 mysql java 后端
于 2024-08-23 20:36:12 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_41679316/article/details/141474254
版权

 背景

 今天遇到接口查询比较慢的两个场景，分析一下并如何优化

场景1：导入文件预览，目的将文件中的企业和标签进行导入后分析和标签是否存在，并返回关联关系，展示出来再有操作人观察是否需要修改再提交更新。在查询预览这个接口导入1700+数据每条数据关联标签平均3个，需要近7分钟

场景2：企业查询列表，企业表、标签关联表、标签表、连表查询，企业数据22w+,测试环境（已标签关联数据29）3s内，线上（9000个标签关联数据）直接响应不回来了

场景1

大致逻辑
1、读取文件转为，企业-》标签集合
2、遍历企业，查询企业信息，标签信息（标签及分类），企业不存在过滤掉
这个方式1700+条企业数据，耗时：将近7分钟
整体逻辑没毛病，也都是走索引查询的，但问题就在单条遍历，每天需要查数据库3次（企业、标签、标签分类）按这个逻辑计算1700*3*3，需要交互15300次，
这种方式数据量小百来条还能忍受数据量一大就不行了。
优化1：
思路：因为都能走索引，可以批量查找减少交互次数，从而较少耗时
修改代码第二步将企业遍历改为分片遍历，每次500个企业，标签和分类联合查询，交互次数：for循环变为1700/500=4，企业1次，标签和分类1次，最终4*2=8次
交互次数重15300->8,缩小1900+倍
效果：耗时：2-3s，提升100-200倍，虽然随之数据量增加效果会骤减，但因为是企业数据量不会特别大，所以已经够了。
优化2：
思路：多线程+缓存，标签查询逻辑可加入缓存，如果还行提升可以多线程，将分片交个多个线程再分片执行，后汇总；因为标签不容易变动所以可以加缓存
代码优化前：
 public List<KeyEnterpriseRelationTagImportPreviewVO> importRelationTagPreview(MultipartFile file) {
        //...文件转为对象List<Object> objects
 
				//企业-》标签集合
        Map<String, List<String>> creditCodeAndTagMap = objects.stream().map(object -> (KeyEnterpriseRelationTagImportExcel) object)
        .filter(object -> StringUtils.isNotBlank(object.getCreditCode()))
        .collect(Collectors.toMap(KeyEnterpriseRelationTagImportExcel::getCreditCode, value -> {
            List<String> tags = Lists.newArrayList();
            if (StringUtils.isNotEmpty(value.getTagName())) {
                tags.addAll(Lists.newArrayList(value.getTagName().split(SPLIT_CHART)));
            }
            if (StringUtils.isNotEmpty(value.getTagName())) {
                tags.addAll(Lists.newArrayList(value.getCompanyTypeName().split(SPLIT_CHART)));
            }
            return tags;
        }));
				//按企业遍历，查询企业信息，以及标签集合
        List<KeyEnterpriseRelationTagImportPreviewVO> voList = Lists.newArrayList();
        for (Map.Entry<String, List<String>> entry : creditCodeAndTagMap.entrySet()) {
            KeyEnterpriseRelationTagImportPreviewVO previewVO = new KeyEnterpriseRelationTagImportPreviewVO();
            String creditNo = entry.getKey();
            BizKeyEnterprise bizKeyEnterprise = bizKeyEnterpriseService.getOne(new LambdaQueryWrapper<BizKeyEnterprise>()
                    .select(BizKeyEnterprise::getCreditNo,
                            BizKeyEnterprise::getCompanyName)
                    .eq(BizKeyEnterprise::getCreditNo, creditNo));
            //如果需要标记不存在的企业
            if (bizKeyEnterprise == null) {
                continue;
            }
            voList.add(previewVO);
            EnterpriseDTO enterpriseDTO = new EnterpriseDTO();
            enterpriseDTO.setCreditNo(bizKeyEnterprise.getCreditNo());
            enterpriseDTO.setName(bizKeyEnterprise.getCompanyName());
            previewVO.setInfo(enterpriseDTO);
            List<String> value = entry.getValue();
            if (CollectionUtils.isEmpty(value)) {
                continue;
            }
            List<KeyEnterpriseTagAndCategoryVO> tagList = value.stream().distinct().map(tagName -> {
                if (StringUtils.isBlank(tagName)) {
                    return null;
                }
                BizKeyEnterpriseTag tag = bizKeyEnterpriseTagService.getOne(new LambdaQueryWrapper<BizKeyEnterpriseTag>()
                        .eq(BizKeyEnterpriseTag::getName, tagName)
                        .eq(BizKeyEnterpriseTag::getDisabled, false)
                );
                if (tag != null) {
                    KeyEnterpriseTagAndCategoryVO keyEnterpriseTagAndCategoryVO = new KeyEnterpriseTagAndCategoryVO();
                    keyEnterpriseTagAndCategoryVO.setCreditNo(bizKeyEnterprise.getCreditNo());
                    keyEnterpriseTagAndCategoryVO.setTagId(tag.getId());
                    keyEnterpriseTagAndCategoryVO.setTagName(tag.getName());

                    BizKeyEnterpriseTagCategory category = bizKeyEnterpriseTagCategoryService.getOne(new LambdaQueryWrapper<BizKeyEnterpriseTagCategory>()
                            .eq(BizKeyEnterpriseTagCategory::getId, tag.getCategoryId()));
                    if (category != null) {
                        keyEnterpriseTagAndCategoryVO.setCategoryId(category.getId());
                        keyEnterpriseTagAndCategoryVO.setCategoryName(category.getName());
                    }
                    return keyEnterpriseTagAndCategoryVO;
                }
                return null;
            }).filter(Objects::nonNull).collect(Collectors.toList());
            previewVO.setTagList(tagList);
        }
        return voList;
    }
 优化后：
  public List<KeyEnterpriseRelationTagImportPreviewVO> importRelationTagPreview(MultipartFile file) {
       //...文件转为对象List<Object> objects

				//企业-》标签集合
        Map<String, List<String>> creditCodeAndTagMap = objects.stream().map(object -> (KeyEnterpriseRelationTagImportExcel) object)
                .filter(object -> StringUtils.isNotBlank(object.getCreditCode()) || (StringUtils.isNotBlank(object.getTagName()) && StringUtils.isNotBlank(object.getCompanyTypeName())))
                .collect(Collectors.toMap(KeyEnterpriseRelationTagImportExcel::getCreditCode, value -> {
                    List<String> tags = Lists.newArrayList();
                    if (StringUtils.isNotEmpty(value.getTagName())) {
                        tags.addAll(Lists.newArrayList(value.getTagName().split(SPLIT_CHART)));
                    }
                    if (StringUtils.isNotEmpty(value.getCompanyTypeName())) {
                        tags.addAll(Lists.newArrayList(value.getCompanyTypeName().split(SPLIT_CHART)));
                    }
                    return tags;
                }));

        List<KeyEnterpriseRelationTagImportPreviewVO> voList = Lists.newArrayList();
        Set<String> creditNos = creditCodeAndTagMap.keySet();
        //优化：单个遍历改为分片，查询企业信息，以及标签集合
        int forCount = creditNos.size() % LIMIT == 0 ? creditNos.size() / LIMIT : creditNos.size() / LIMIT + 1;
        for (int i = 0; i < forCount; i++) {
            List<String> limitCreditNos = creditNos.stream().skip((long) i * LIMIT).limit(LIMIT).collect(Collectors.toList());
            List<BizKeyEnterprise> bizKeyEnterprises = bizKeyEnterpriseService.list(new LambdaQueryWrapper<BizKeyEnterprise>()
                    .select(BizKeyEnterprise::getCreditNo,
                            BizKeyEnterprise::getCompanyName)
                    .in(BizKeyEnterprise::getCreditNo, limitCreditNos)
                    .groupBy(BizKeyEnterprise::getCreditNo)
            );

            if (CollectionUtils.isEmpty(bizKeyEnterprises)) {
                continue;
            }
            //标签去重
            Set<String> tagNames = Sets.newHashSet();
            bizKeyEnterprises.forEach(bizKeyEnterprise -> {
                tagNames.addAll(creditCodeAndTagMap.get(bizKeyEnterprise.getCreditNo()));
            });
            List<KeyEnterpriseTagAndCategoryVO> tagList = bizKeyEnterpriseTagService.listTagName(tagNames, null);
            Map<String, KeyEnterpriseTagAndCategoryVO> tagNameAndTagVO = tagList.stream().collect(Collectors.toMap(KeyEnterpriseTagAndCategoryVO::getTagName, Function.identity()));
            for (BizKeyEnterprise bizKeyEnterprise : bizKeyEnterprises) {
                KeyEnterpriseRelationTagImportPreviewVO previewVO = new KeyEnterpriseRelationTagImportPreviewVO();
                voList.add(previewVO);
                EnterpriseDTO enterpriseDTO = new EnterpriseDTO();
                enterpriseDTO.setName(bizKeyEnterprise.getCompanyName());
                enterpriseDTO.setCreditNo(bizKeyEnterprise.getCreditNo());
                previewVO.setInfo(enterpriseDTO);
                List<String> tagNameList = creditCodeAndTagMap.get(bizKeyEnterprise.getCreditNo());
                if (CollectionUtils.isEmpty(tagNameList)) {
                    continue;
                }
                previewVO.setTagList(tagNameList.stream().map(tagName -> {
                    KeyEnterpriseTagAndCategoryVO vo = tagNameAndTagVO.get(tagName);
                    if(vo == null) return null;
                    vo.setCreditNo(bizKeyEnterprise.getCreditNo());
                    return vo;
                }).filter(Objects::nonNull).collect(Collectors.toList()));
            }
        }
        return voList;
    }

场景2

大致逻辑：企业列表，通过企业部分字段、标签、标签类别查询企业，返回企业部分字段关联标签、标签分类

sql优化前，不管是否需要用到标签表都left join,按线上现有数据量计算，220000*9000=1980000000，将近20亿扫描😂，难怪不响应了
一开始有人说给关系表加索引（这种其实没效果，因为区分度不大，标签才71个,有9000条关系），但给同事看，建了索引分析结果如下：
+----+-------------+-------+------------+--------+--------------------------------+---------+---------+----------------------------------+--------+----------+------------------------------------------------+
| id | select_type | table | partitions | type   | possible_keys                  | key     | key_len | ref                              | rows   | filtered | Extra                                          |
+----+-------------+-------+------------+--------+--------------------------------+---------+---------+----------------------------------+--------+----------+------------------------------------------------+
|  1 | SIMPLE      | dci   | NULL       | ALL    | credit_no_IDX                  | NULL    | NULL    | NULL                             | 204510 |   100.00 | Using temporary; Using filesort                |
|  1 | SIMPLE      | bketr | NULL       | ALL    | credit_no_idx                  | NULL    | NULL    | NULL                             |   8514 |   100.00 | Range checked for each record (index map: 0x2) |
|  1 | SIMPLE      | bket  | NULL       | eq_ref | PRIMARY                        | PRIMARY | 8       | bketr.tag_id                     |      1 |   100.00 | Using index                                    |
+----+-------------+-------+------------+--------+--------------------------------+---------+---------+----------------------------------+--------+----------+------------------------------------------------+
未加索引分析结果
+----+-------------+-------+------------+--------+--------------------------------+---------+---------+----------------------------------+--------+----------+----------------------------------------------------+
| id | select_type | table | partitions | type   | possible_keys                  | key     | key_len | ref                              | rows   | filtered | Extra                                              |
+----+-------------+-------+------------+--------+--------------------------------+---------+---------+----------------------------------+--------+----------+----------------------------------------------------+
|  1 | SIMPLE      | dci   | NULL       | ALL    | credit_no_IDX                  | NULL    | NULL    | NULL                             | 204510 |   100.00 | Using temporary; Using filesort                    |
|  1 | SIMPLE      | bketr | NULL       | ALL    | NULL                           | NULL    | NULL    | NULL                             |   8514 |   100.00 | Using where; Using join buffer (Block Nested Loop) |
|  1 | SIMPLE      | bket  | NULL       | eq_ref | PRIMARY                        | PRIMARY | 8       | bketr.tag_id                     |      1 |   100.00 | Using index                                        |
+----+-------------+-------+------------+--------+--------------------------------+---------+---------+----------------------------------+--------+----------+----------------------------------------------------+
通过对比，发现虽然加了索引后识别到索引了，但并没有使用（区别度不高，mysql不走索引，走全表扫描）
通过sql分析，查询结果并不需要返回标签相关数据（其实是另外的优化，因为企业和标签1：n想要一个sql写出来也可以通过聚合查询将同个企业标签聚合在一个字段，
但成本很高，且sql也阅读性也差，就先查出企业信息，返回之后再对企业查出对应标签），这是在未加条件的情况下，是不需要联合查询的那么通过iBatis的<if>标签来
动态拼接联合表，这样在没有条件下只需要扫描企业表22W+数据比20亿数据快几千倍。

mapper.xml
优化前
   select dci.credit_no, dci.company_name, dci.company_type_name, dci.company_sub_type, dci.street_name, dci.industry_platform_name, dci.industry_type_name
        from dwd_company_info dci
             left join biz_key_enterprise_tag_relation bketr on dci.credit_no =bketr.credit_no and bketr.source_type=0
             left join biz_key_enterprise_tag bket on bketr.tag_id = bket.id
        <include refid="pageKeyEnterpriseBaseDataWhere"/>
        group by dci.credit_no
优化后
   select dci.credit_no, dci.company_name, dci.company_type_name, dci.company_sub_type, dci.street_name, dci.industry_platform_name, dci.industry_type_name
        from dwd_company_info dci
			      <if test="(req.tagIds!= null and req.tagIds.size() > 0) or (req.categoryId!= null and req.categoryId!= '')">
             left join biz_key_enterprise_tag_relation bketr on dci.credit_no =bketr.credit_no and bketr.source_type=0
             left join biz_key_enterprise_tag bket on bketr.tag_id = bket.id
		        </if>
        <include refid="pageKeyEnterpriseBaseDataWhere"/>
        group by dci.credit_no

那么这时又有人问，那加了标签条件非索引字段那不还是要扫描20亿数据，（心想这小子没想到MySQL优化器的存在呀！得给他分析一下，顺便复习一下😄）
例子：筛选条件选择标签分类id=4，分享结果如下：
 explain select dci.credit_no, dci.company_name, dci.company_type_name, dci.company_sub_type, dci.street_name, dci.industry_platform_name, dci.industry_type_name from dwd_company_info dci left join biz_key_enterprise_tag_relation bketr on dci.credit_no =bketr.credit_no and bketr.source_type=0 left join biz_key_enterprise_tag bket on bketr.tag_id = bket.id WHERE bket.category_id = 4 group by dci.credit_no;
+----+-------------+-------+------------+--------+--------------------------------+--------------------------------+---------+-------------------------------------+------+----------+------------------------------+
| id | select_type | table | partitions | type   | possible_keys                  | key                            | key_len | ref                                 | rows | filtered | Extra                        |
+----+-------------+-------+------------+--------+--------------------------------+--------------------------------+---------+-------------------------------------+------+----------+------------------------------+
|  1 | SIMPLE      | bketr | NULL       | ALL    | NULL                           | NULL                           | NULL    | NULL                                |90000 |    10.00 | Using where; Using temporary |
|  1 | SIMPLE      | bket  | NULL       | eq_ref | PRIMARY                        | PRIMARY                        | 8       | enterprise-workflow.bketr.tag_id    |    1 |    10.00 | Using where                  |
|  1 | SIMPLE      | dci   | NULL       | ref    | dwd_company_info_credit_no_IDX | dwd_company_info_credit_no_IDX | 1023    | enterprise-workflow.bketr.credit_no |    1 |   100.00 | Using index condition        |
+----+-------------+-------+------------+--------+--------------------------------+--------------------------------+---------+-------------------------------------+------+----------+------------------------------+
通过分析结果可以看出来MySQL优化器还是比较智能的，会先将关联表过滤一遍得到结果，和标签表id关联（命中主键索引）结果再和企业表关联（命中普通索引credit_no）,总共才扫描到9000行
并没有想象中先联合后再过滤出数据，这是MySQL优化器判断出那种方式更优（并不是所有情况都能正确选择到最优解）

🤗 总结归纳

这两个场景都不是直接通过优化sql的手段来提高效率的，都是通过优化编码逻辑技巧优化，情景1：较少数据库请求次数，情景2：减少联合表+MySQL自身优化器。

场景2需要通过工具分析执行计划来论证优化内容。

free-brid
关注
专栏目录
【问题排查】记一次慢接口排查优化
Coinker的博客
12-23 1620
最近做项目的一个接口查询总是很慢，有时要用好几秒，甚至十几秒，底层用的是Tidb数据库，而且是多线程查，一次请求也就两个sql，按理说这是不应该的，本着刨根问底的心态，我对该慢接口进行了分析排查。 接口名称：查询店铺评价详情列表 接口URL：http://127.0.0.1:8890/ads/api/v1/app/xxxxxx/xxxxxxx 接口响应时间（测试环境）： ① 第一次：24.77s ② 第二次：15.09s ③ 第三次：16.79 通过测试我们可以发现，平均每次调用都在15s左右，甚至更高.
sql查询速度太慢怎么优化
youngpeople_的博客
01-20 1万+
今天群里的小伙伴问的问题 在这里分析一下sql查询速度太慢怎么优化 原因分析 后台数据库中数据过多，未做数据优化 数据请求-解析-展示处理不当 网络问题 提高数据库查询的速度方案 SQL 查询速度慢的原因有很多，常见的有以下几种： 1、没有索引或者没有用到索引(查询慢最常见的问题，是程序设计的缺陷) 2、I/O吞吐量小，形成了瓶颈效应。 3、没有创建计算列导致查询不优化。 4、内存不足 5、网络速度慢 6、查询出的数据量过大（可以采用多次查询，其他的方法降低数据量） 7、锁或者死锁(这也是查询慢最常..
Java多线程实战-CompletableFuture异步编程优化查询接口响应速度
热门推荐
qq_35716689的博客
03-20 25万+
CompletableFuture为Java提供了强大的异步编程能力,可以极大地提高应用的并发能力和响应速度。通过并行执行多个查询任务,我们可以大幅减少接口的响应时间,优化用户体验。同时,CompletableFuture的代码风格函数式、简洁、优雅,也使得代码更加易读易维护。 但是,异步编程也不是万能的,它需要开发者转变思维模式,还需要权衡利弊。在实际项目中,我们可以结合其他优化手段,选择合适的方案,以达到最佳的性能效果。
SQL慢查询优化方式
echola_mendes的博客
08-28 2358
MYSQL优化一般从SQL语句开始优化，再分析索引，即使有了良好的索引，糟糕的查询语句也可能导致性能问题优化查询语句可以帮助数据库更有效地利用现有的资源，减少不必要的开销。
接口响应慢的优化方案
阿木木
03-02 2400
接口响应变慢，或突然无响应
接口性能优化方法总结
mischen520的博客
06-23 1525
将一些经常查询需要的固定不变的数据加入到缓存中，请求的时候优先从缓存里面去取数据，这样会大大提高接口的查询性能，因为缓存是存在内存中的，避免了大量的数据库查询。在操作Redis和数据库时，要么两者都成功，要么都失败，使用数据库的事务可以保证这一点。当系统发展到一定阶段，用户并发量增加，会有大量的数据库请求，这不仅需要占用大量的数据库连接，还会带来磁盘IO的性能瓶颈问题。为了提升接口性能，尤其在高并发场景下，可以考虑数据冗余，将用户信息、积分和成长值的数据统一存储在一个地方，比如Redis。
接口访问速度慢？你可以这么优化
分享一些工作和生活中的一些心得，主要分享一些Java和JavaScript方面的知识，也会包括服务器运维等其他知识
04-24 8910
前言 最近开发中遇到一个问题，有一个请求非常慢，在本地环境需要6s左右，正式环境也需要1.5s以上，这个肯定不行，需要优化。 分析之后，发现接口需要5s左右，前端也没有使用异步请求，导致页面非常卡顿。 接口慢就需要针对接口进行优化，首先想到的就是SQL层面的优化，由于是一个很复杂的报表查询逻辑，数据库层面优化之后还是不理想，于是决定进行代码层面的处理。首先是将SQL进行了拆分，拆分成了三条SQL各自取值，然后在代码中合并计算。然后使用多线程，让三条SQL同步执行。最后优化后本地环境从最开始的6s左右的时间变
mysql慢查询优化
m0_51290829的博客
04-15 7875
前言 在应用开发的早期，数据量少，开发人员开发功能时更重视功能上的实现，随着生产数据的增长，很多 SQL 语句开始暴露出性能问题，对生产的影响也越来越大，有时可能这些有问题的 SQL 就是整个系统性能的瓶颈。 提示：以下是本篇文章正文内容，下面案例可供参考 一、sql语句执行顺序 FROM(form) 先确定从哪个表中取数据，所以最先执行from tab。存在多表连接，from tab1，tab2。可以对表加别名，方便后面的引用。 ON(on) 连接多张表的附加条件 JOIN(join) 连
Java后端服务接口性能优化常用技巧
m0_49692893的博客
02-25 1429
对于高标准程序员来说提供高性能的服务接口是我们所追求的目标，以下梳理了一些提升接口性能的技术方案，希望对大家有所帮助。
接口优化从20s优化到500ms
BUG指挥课堂
10-14 1515
接口性能问题，对于从事后端开发的同学来说，是一个绕不开的话题。想要优化一个接口的性能，需要从多个方面着手。其实，我之前也写过一篇接口性能优化相关的文章《聊聊接口性能优化的11个小技巧》，发表之后在全网广受好评，感兴趣的小伙们可以仔细看看。本文将会接着接口性能优化这个话题，从实战的角度出发，聊聊我是如何优化一个慢查询接口的。上周我优化了一下线上的批量评分查询接口，将接口性能从最初的20s，优化到目前的500ms以内。总体来说，用三招就搞定了。到底经历了什么？
一个20秒SQL慢查询优化的经历与处理方案
12-14
　前几天在项目上线过程中，发现有一个页面无法正确获取数据，经排查原来是接口调用超时，而后发现是因为SQL查询长达到20多秒而导致了问题的发生。 　这里，没有高深的理论或技术，只是备忘一下经历和解读一些思想...
Java 实现一个接口里面，查询多次数据库导致慢，优化方法来了（亲测有效）
一天不写代码难受的博客
12-26 4407
接口优化
Ubuntu有关redis的命令
weixin_53717695的博客
10-06 285
Ubuntu有关redis的命令
鲁班到家上门安装维修系统源码开发之结构功能解析
weixin_43744973的博客
10-08 922
鲁班到家上门安装维修系统的源码开发是一个复杂但富有成效的过程。通过详细的需求分析、技术选型、功能模块设计以及前后端分离开发，该系统不仅提升了服务效率，还通过数字化管理优化了用户体验。未来，该系统有望在智能家居售后服务领域发挥更加重要的作用，引领行业向更加高效、专业、透明的方向发展。
ATAM需求说明-系统架构师（七十六）
ke1ying的博客
10-08 865
1体系结构权衡分析法ATAM(Architecture Trade Off Analyzer Method)是一种常见的结构权衡分析法，该框架主要关注系统的（），针对性能、安全性、可用性和可修改性，在系统开发前进行分析、评价和这种。A共享数据库的集成方式通常将应用程序的数据存储在一个共享数据库中，通过制定统一的数据库模式来处理不同应用集成需求。场景和需求的收集，架构视图和场景的实现，属性模型的构造和分析，架构评价和折中。7企业信息资源集成管理的前提是对企业（）的集成，其核心是对企业（）的集成。
World of Warcraft [CLASSIC][80][Grandel] Call to Arms: Victory in Wintergrasp
qq 117791303
10-02 354
Wintergrasp 冬拥湖 120 VS 120
应对Redis大Key挑战：从原理到实现
最新发布
欢迎来到【技术拾光者】，在这里，我们专注分享编程教程、技术趋势、实战案例和优质资源。不定期举办技术问答、专家访谈和职业指导。加入我们，共同探索技术世界，提升技能，拓展职业道路！
10-09 962
在使用Redis时，大Key问题会导致性能下降、内存消耗过多等问题。本文详细探讨了大Key问题的成因、影响及解决方案。大Key问题通常由大字符串、大集合或大对象引起，影响系统的内存使用和响应时间。通过拆分大Key、分页读取、异步删除和监控预警等方法，可以有效解决大Key问题。文章提供了Java示例代码，展示如何处理和优化Redis中的大Key问题，包括手动拆分大Key、分页读取大集合和异步删除大Key等。通过这些方法，开发者可以显著提升Redis的性能和稳定性。
同城O2O系统源码与跑腿配送平台的架构设计与开发方案详解
meihusdk的博客
10-08 430
同城O2O系统与跑腿配送平台的开发，既是技术的挑战，也是商业机会的探索。通过合理的架构设计与清晰的开发方案，开发者可以构建出高效、稳定且易于扩展的平台，为用户提供更为便捷的服务。
思迅商云开启货号修改语句
xushugang007的博客
10-03 242
insert into t_sys_system (sys_var_id,sys_var_name,sys_var_value,is_changed,sys_ver_flag) values('itemnoisedit','货号、供应商、客户编码修改','1','否','1')use hbposv10 --分店数据库名改成： hbposv10_branch。--开启 货号、供应商、客户编码修改。
API接口优化实践：解决慢查询与性能瓶颈
1. 数据库慢查询 - 深度分页问题：深度分页会导致数据库加载大量无用数据，从而降低性能。解决方法是通过添加条件，如`id > lastId`，利用主键索引直接定位到所需数据，但这需要调用方配合传递上一次查询的最大ID，...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值