1. Oinone社区首页

深度分页问题优化方案

• • Uncategorized • 阅读 655

问题原因

Mysql使用select * from table limit offset, rows分页在深度分页的情况下, 性能急剧下降。

例如：select * 的情况下直接⽤limit 600000，10 扫描的是约60万条数据，并且是需要回表 60W次，也就是说⼤部分性能都耗在随机访问上，到头来只⽤到10条数据(总共取600010条数据只留10条记录)

优化方案

前端方案：业务层面限制跨度比较大的跳页

提供2种风格分页器供用户选择

  1. 标准分页器，展示最后一页和跳转指定页输入框
    image.png
  2. 简单分页器
    image.png

参考
百度方案: 不展示最后一页和直接跳转指定分页的输入框
image.png
Google方案：只展示查看下一页的按钮
image.png

界面设计器选表格/画廊的属性面板提供分页器风格的属性下拉选择

image.png

xml示例

<!-- 表格使用的标准分页器 -->
<view type="TABLE" paginationStyle="SIMPLE">
 <!-- fields -->
</view>

<!-- 画廊使用默认的标准分页器 -->
<view type="GALLERY" paginationStyle="STANDARD">
 <!-- fields -->
</view>

后端方案

  1. 使用索引：确保数据库表中的相关字段上创建了适当的索引。索引可以加快查询速度，特别是在处理大数据量时。

  2. 分批查询：将大数据分成多个较小的批次进行查询，而不是一次性查询全部数据。可以通过限制每次查询的数据量和使用合适的偏移量来实现分批查询，例如使用LIMIT和OFFSET子句。

  3. 基于游标的分页：使用基于游标的分页技术，而不是传统的偏移分页。游标分页是通过记录上一次查询的游标位置，在下一次查询时从该位置开始获取新的数据，避免了大偏移量的影响。这可以通过数据库自身的功能（例如MySQL的CURSOR）或使用第三方库来实现。

  4. 缓存数据：如果数据变化较少，可以考虑将查询结果缓存到内存中，以避免频繁地查询数据库。这样可以提高页面相应速度，并减轻数据库负担。缓存的数据应该根据业务需要及时更新。

  5. 数据预处理：如果查询结果经常需要进行复杂的计算或处理，可以考虑提前对数据进行预处理并缓存结果，以减少每次查询的计算负担。

  6. 数据库优化：针对具体数据库系统，可以根据实际情况进行数据库调优。例如，合理设置数据库连接池大小、调整数据库参数等。

  7. 分布式存储和计算：对于非关系型数据库或分布式存储系统，可以考虑使用分布式存储和计算方案，将数据分散存储在多个节点上，并通过计算节点并行处理查询请求，以提高性能和可伸缩性。

参考链接

MySQL深分页场景下的性能优化

Oinone社区 作者：原创文章，如若转载，请注明出处：https://doc.oinone.top/other/75.html

访问Oinone官网:https://www.oinone.top获取数式Oinone低代码应用平台体验

赞 (0)
的头像
0 0
上一篇 2023年6月20日 pm4:07
下一篇 2023年11月2日 pm1:58

相关推荐

  • mybatis拦截器的使用 代码实践

    mybatis拦截器的使用

    场景：自定义拦截器做数据的加解密。 注册自定义拦截器 @Configuration public class MyBatisConfig { // TODO: 注册自定义拦截器 @Bean @Order(999) public EncryptionInterceptor encryptionInterceptor() { return new EncryptionInterceptor(); } } 使用mybatis拦截器拦截查询。 @Intercepts({ @Signature(type = Executor.class, method = "update", args = {MappedStatement.class, Object.class}), @Signature(type = Executor.class, method = "query", args = {MappedStatement.class, Object.class, RowBounds.class, ResultHandler.class}) }) public class EncryptionInterceptor implements Interceptor { @Autowired private EncryptionConfig encryptionConfig; @Override public Object intercept(Invocation invocation) throws Throwable { Object[] args = invocation.getArgs(); MappedStatement ms = (MappedStatement) args[0]; Object parameter = args[1]; // 判断操作类型是insert, update 或 delete if (ms.getSqlCommandType().equals(SqlCommandType.INSERT) || ms.getSqlCommandType().equals(SqlCommandType.UPDATE) || ms.getSqlCommandType().equals(SqlCommandType.DELETE)) { // TODO: 加密字段 encryptFields(parameter); } else if (ms.getSqlCommandType().equals(SqlCommandType.SELECT)) { // TODO: 查询操作，在执行后需要对结果进行解密 Object result = invocation.proceed(); List<EncryptionConfig.Models> models = encryptionConfig.getModels(); for (EncryptionConfig.Models model : models) { if (judgmentModel(parameter, model)) { decryptFields(result); } } return result; } return invocation.proceed(); } private Boolean judgmentModel(Object parameter, EncryptionConfig.Models model) { MetaObject metaObject = SystemMetaObject.forObject(parameter); if (metaObject.getOriginalObject() instanceof MapperMethod.ParamMap) { if (metaObject.hasGetter("ew")) { Object param1 = metaObject.getValue("ew"); if (param1 != null) { Object originalObject = SystemMetaObject.forObject(param1).getOriginalObject(); if (originalObject instanceof QueryWrapper) { DataMap entity = (DataMap) ((QueryWrapper<?>) originalObject).getEntity(); if (entity != null) { Object modelFieldName = entity.get(FieldConstants._d_modelFieldName);…

    yexiu的头像 yexiu
    2024年12月2日
    1.1K00
  • 5.8 商业支撑之执行域 Oinone 7天入门到精通

    5.8 商业支撑之执行域

    一、基础介绍 执行域包括两个核心一是订单的产生，二是订单的履约。往往品牌商既有自营渠道（包括2c、2b）、又有第三方渠道。那么有两种设计思路： 把第三方渠道的订单当作自有渠道的订单产生一种特殊方式，开放订单创建接口，并统一履约。 好处：简单，在3方渠道不多、且自有渠道单一，并且逻辑相识时系统结构会简单 坏处： 当3方渠道的履约方式、库存分配方式、逆向逻辑等有差异时，会让自有渠道参杂很多不相干的逻辑引入不必要的复杂度 自有渠道不够独立和纯粹，自有渠道多样化时难以支撑 把商家自营渠道假设为特殊的第三方渠道，再建立统一的订单管理系统来对接渠道订单，并完成履约 好处：交易与履约逻辑分离，对未来发展有扩展性 坏处：引入一定复杂度 我们采用的是第二套方案，整体结构简易图如下 图5-8-1 方案整体结构简易图 二、模型介绍 图5-8-2 模型介绍 核心设计逻辑 首先我们看到上图交易域和履约域有很多相同父模型的子模型，交易域和履约域的父模型在CDM的在himalaya-trade里。履约域看oms（libra）对himalaya-trade扩展，交易域看b2c（leo）和b2b（aries）对对himalaya-trade扩展。libra、leo、aries是我们对上层业务产品的命名，取自黄道十二星座 交易域是多商家平台视角设计，有自身渠道必要的履约相关信息，完成自闭环。 履约域是从单一商家对接多渠道视角设计，有渠道交易订单同步后完成履约发货相关设计，完成自闭环。 履约域的合单拆单发货设计，渠道订单只能合单为履约单不可拆，履约单可以拆单发货不可合。用m2o和o2m的组合设计来降低难度，而非采用两个m2m的设计。

    史, 昂的头像 史, 昂
    2024年5月23日
    1.0K00
  • O2M、M2O、M2M关系字段配置问题以及问题排查路径 问题诊断

    O2M、M2O、M2M关系字段配置问题以及问题排查路径

    M2O关系字段 配置示例： @Field(displayName = “教师关联学生”) @Field.many2one @Field.Relation(relationFields = {“studentName”}, referenceFields = {“name”}) private Student students; 解析： 在这个多对一关系中，studentName为本模型的字段，name为Student的字段，这个多对一关系通过这两个字段关联起来。 在保存该关联关系时，会将name的值带到studentName里并保存在当前模型中（many） studentName字段必须是存储字段，因为在查询many的数据的时候是通过这个字段进行查询的。 name必须在关系模型即Student里面定义（one），studentName在本模型里面定义不定义都可以，如果没有的话会在本模型中创建该字段。 常见问题： 启动报错：根据报错内容进行相应修改 保存报错：Duplicate entry '******' for key 'PRIMARY'，报这个错是因为studentName是唯一键，在将相同name的值赋值给studentName时导致唯一键冲突。其他关系也会有此情况。 O2M关系字段 配置示例： @Field(displayName = "教师关联宠物") @Field.one2many @Field.Relation(relationFields = {"id"}, referenceFields = {"teacherId"}) private List<PetShop> studentsCode; 解析： 在这个一对多关系中，id为本模型的字段，teacherId为PetShop的字段，这个一对多关系通过这两个字段关联起来。 在保存该关联关系时，会将id的值带到teacherId里并保存在PetShop模型中（many） id必须在本模型中定义（one）, teacherId在PetShop模型里面定义不定义都可以，如果没有的话会在PetShop模型中创建该字段。 常见问题： 启动报错：根据报错内容进行相应修改 保存报错：请先保存关联关系模型：如果 id 为自定义字段 与 PetShop进行关联，那么保存关联关系时必须给id 赋值，不然会报错 M2M关系字段 配置示例1： @Field.many2many(through = OrderRelLogistics.MODEL_MODEL, relationFields = {"parentOrderId"}, referenceFields = {"logisticsBillId"}) @Field.Relation(relationFields = {"id"}, referenceFields = {"id"}) @Field(displayName = "物流单") private List<LogisticsBill> logisticsBillList; 解析： 在这个多对多关系中，id（左）为本模型的字段，id（右）为PetShop的字段。OrderRelLogistics.MODEL_MODEL为中间表，在保存关联关系时中间表会维护双方的关系字段，id（左）的值写到中间表的parentOrderId字段，id（右）的值写到中间表的logisticsBillId字段。 常见问题： 保存报错，请先保存关联关系模型：如果id（左）为在本模型自定义的字段，则需要在保存关联关系的时候的时候将该自定义赋值，这样才能正确保存关联关系。 配置示例2： 新增TalentTypeEnum @Dict(dictionary = TalentTypeEnum.DICTIONARY,displayName = “达人类型”) public class TalentTypeEnum extends BaseEnum { public static final String DICTIONARY =”top.TalentTypeEnum”; public final static TalentTypeEnum DOG =create(“DOG”,1,”狗达人”,”狗达人”); public final static TalentTypeEnum CAT =create(“CAT”,2,”猫达人”,”猫达人”); } 中间表定义 @Model.model(PetItemRelPetTalent.MODEL_MODEL) @Model(displayName = “中间表”, summary = “中间表”) public class PetItemRelPetTalent extends BaseRelation { public static final String MODEL_MODEL = “top.PetItemRelPetTalent”; @Field.String @Field(displayName = “商店ID”) private String petItemId; @Field.String @Field(displayName = “宠物ID”) private String petTalentId; @Field.String @Field(displayName = “宠物类型”) private TalentTypeEnum talentType; } 关系字段定义（关联关系中，使用”##“包括定义常量，这里定义常量"test"） @Field(displayName = “推荐达人”) @Field.many2many( through = PetItemRelPetTalent.MODEL_MODEL, relationFields = {“petItemId”}, referenceFields = {“petTalentId”,”talentType”} ) @Field.Relation(relationFields = {“id”}, referenceFields = {“id”, “#2#”})…

    yexiu的头像 yexiu
    2024年8月9日
    1.5K00
  • 函数如何跳过权限拦截 问题诊断

    函数如何跳过权限拦截

    跳过登录直接调用接口 示例： 跳过queryTea的权限验证 @Action(displayName = "queryTea", bindingType = ViewTypeEnum.FORM) @Action.Advanced(type = FunctionTypeEnum.UPDATE) public Teacher queryTea(Teacher data) { } 在yaml文件里面配置上该函数的namespace（模型编码）以及函数名字 pamirs: auth: fun-filter: – namespace: user.PamirsUserTransient fun: login #登录 – namespace: top.Teacher fun: queryTea 不跳过登录直接调用接口 示例： 在yaml文件里面配置上该函数的namespace（模型编码）以及函数名字 pamirs: auth: fun-filter-only-login: #登录后不再校验该函数的权限 – namespace: top.Teacher fun: queryTea 按包设置权限过滤 如何批量跳过权限验证？以上两种方式提供了在yml文件里面配置权限过滤的方式，但如果需要大量过滤权限，配置就变得很繁琐，所以下面主要介绍通过代码扩展的方式去控制权限。 示例： 以下示例通过控制包路径来跳过权限。 继承pro.shushi.pamirs.auth.api.spi.AuthFilterService接口 import org.springframework.core.annotation.Order; import org.springframework.stereotype.Component; @Order(88) @Component public class CustomAuthFilterService implements AuthFilterService { public static final String skipClass = "pro.shushi.pamirs.top.core.action"; @Override public Boolean isAccessAction(String model, String name) { //从缓存中取函数 Action cacheAction = PamirsSession.getContext().getExtendCache(ActionCacheApi.class).get(model, name); if (cacheAction instanceof ServerAction) { ServerAction serverAction = (ServerAction) cacheAction; Function function = PamirsSession.getContext().getFunction(serverAction.getModel(), serverAction.getFun()); String clazz = function.getClazz(); //返回true就代表通过验证 if (clazz != null && clazz.startsWith(skipClass)) { return true; } } return null; } } 请求pro.shushi.pamirs.top.core.action路径下的动作可以通过验证。

    yexiu的头像 yexiu
    2024年8月22日
    1.2K00
  • Oinone环境保护（v5.2.3以上） 后端

    Oinone环境保护（v5.2.3以上）

    概述 Oinone平台为合作伙伴提供了环境保护功能，以确保在一套环境可以在较为安全前提下修改配置文件，启动多个JVM等部署操作。 本章内容主要介绍与环境保护功能相关的启动参数。 名词解释 本地开发环境：开发人员在本地启动业务工程的环境 公共环境：包含设计器镜像和业务工程的环境 环境保护参数介绍 【注意】参数是加在程序实参 (Program arguments)上，通常可能错误的加在Active Profiles上了 -PenvProtected=${value} 是否启用环境保护，默认为true。 环境保护是通过与最近一次保存在数据库的base_platform_environment表中数据进行比对，并根据每个参数的配置特性进行判断，在启动时将有错误的内容打印在启动日志中，以便于开发者进行问题排查。 除此之外，环境保护功能还提供了一些生产配置的优化建议，开发者可以在启动时关注这些日志，从而对生产环境的配置进行调优。 -PsaveEnvironments=${value} 是否将此次启动的环境参数保存到数据库，默认为true。 在某些特殊情况下，为了避免公共环境中的保护参数发生不必要的变化，我们可以选择不保存此次启动时的配置参数到数据库中，这样就不会影响其他JVM启动时发生校验失败而无法启动的问题。 -PstrictProtected=${value} 是否使用严格校验模式，默认为false 通常我们建议在公共环境启用严格校验模式，这样可以最大程度的保护公共环境的元数据不受其他环境干扰。 PS：在启用严格校验模式时，需避免内外网使用不同连接地址的场景。如无法避免，则无法启用严格校验模式。 常见问题 需要迁移数据库，并更换了数据库连接地址该如何操作？ 将原有数据库迁移到新数据库。 修改配置文件中数据库的连接地址。 在启动脚本中增加-PenvProtected=false关闭环境保护。 启动JVM服务可以看到有错误的日志提示，但不会中断本次启动。 移除启动脚本中的-PenvProtected=false或将值改为true，下次启动时将继续进行环境保护检查。 可查看数据库中base_platform_environment表中对应数据库连接配置已发生修改，此时若其他JVM在启动前未正确修改，则无法启动。 本地开发时需要修改Redis连接地址到本地，但希望不影响公共环境的使用该如何操作？ PS：由于Redis中的元数据缓存是根据数据库差量进行同步的，此操作会导致公共环境在启动时无法正确刷新Redis中的元数据缓存，需要配合pamirs.distribution.session.allMetaRefresh参数进行操作。如无特殊必要，我们不建议使用该形式进行协同开发，多次修改配置会导致出错的概率增加。 本地环境首次启动时，除了修改Redis相关配置外，还需要配置pamirs.distribution.session.allMetaRefresh=true，将本地新连接的Redis进行初始化。 在本地启动时，增加-PenvProtected=false -PsaveEnvironments=false启动参数，以确保本地启动不会修改公共环境的配置，并且可以正常通过环境保护检测。 本地环境成功启动并正常开发功能后，需要发布到公共环境进行测试时，需要先修改公共环境中业务工程配置pamirs.distribution.session.allMetaRefresh=true后，再启动业务工程。 启动一次业务工程后，将配置还原为pamirs.distribution.session.allMetaRefresh=false。

    张博昊的头像 张博昊
    2024年10月21日
    1.4K00

Leave a Reply

登录后才能评论