深度分页问题优化方案

问题原因

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低代码应用平台体验

Like (0)
's avatar
Previous 2023年6月20日 pm4:07
Next 2023年11月2日 pm1:58

相关推荐

  • 【HighGo】后端部署使用HighGo数据库

    HighGo数据库配置 驱动配置 jdbc仓库 https://mvnrepository.com/artifact/com.highgo/HgdbJdbc Maven配置(6.0.1版本可用) <highgo.version>6.0.1.jre8</highgo.version> <dependency> <groupId>com.highgo</groupId> <artifactId>HgdbJdbc</artifactId> <version>${highgo.version}</version> </dependency> JDBC连接配置 pamirs: datasource: base: type: com.alibaba.druid.pool.DruidDataSource driverClassName: com.highgo.jdbc.Driver url: jdbc:highgo://127.0.0.1:5866/oio_base?currentSchema=base,utl_file username: xxxxxx password: xxxxxx initialSize: 5 maxActive: 200 minIdle: 5 maxWait: 60000 timeBetweenEvictionRunsMillis: 60000 testWhileIdle: true testOnBorrow: false testOnReturn: false poolPreparedStatements: true asyncInit: true 连接url配置 官方文档 https://www.highgo.com/document/zh-cn/application/jdbc.html url格式 jdbc:highgo://ip:端口号/数据库名?currentSchema=schema1,schema2 在jdbc连接配置时,${database}和${schema}必须完整配置,不可缺省。 jdbc指定schema时可以在currentSchema后指定多个schema,中间用,分隔,第一个schema为业务库表存放的主schema。 highgo数据库6.0版本里每个数据库默认会带一个utl_file的schema,该模式与文件访问功能有关,需要带在jdbc的schema中,但不能放在第一个。 其他连接参数如需配置,可自行查阅相关资料进行调优。 方言配置 pamirs方言配置 pamirs: dialect: ds: base: type: HighGoDB version: 6 major-version: 6.0.1 biz_data: type: HighGoDB version: 6 major-version: 6.0.1 数据库版本 type version majorVersion 6.0.x HighGo 6 6.0.1 PS:由于方言开发环境为6.0.1版本,其他类似版本(6.0.x)原则上不会出现太大差异,如出现其他版本无法正常支持的,可在文档下方留言。 schedule方言配置 pamirs: event: enabled: true schedule: enabled: true dialect: type: HighGoDB version: 6 major-version: 6.0.1 其他配置 逻辑删除的值配置 pamirs: mapper: global: table-info: logic-delete-value: (EXTRACT(epoch FROM CURRENT_TIMESTAMP) * 1000000 + EXTRACT(MICROSECONDS FROM CURRENT_TIMESTAMP))::bigint Highgo数据库用户初始化及授权 — init oio_base user (user name can be modified by oneself) CREATE USER oio_base WITH PASSWORD 'Test@12345678'; — if using automatic database and schema creation, this is very important. ALTER USER oio_base CREATEDB; SELECT * FROM pg_roles; — if using highgo database, this authorization is required. GRANT CREATE ON DATABASE highgo TO oio_base;

    2025年7月10日
    93300
  • 接口日志内容记录频率限制功能说明

    为有效避免接口调用日志记录占用过多存储空间,从而减少对数据库资源的消耗,自5.2.0之后的版本,对于成功请求的集成接口与开放接口,其日志将不再进行完整记录。请求及响应参数将依据默认的千分之一概率进行选择性完整记录。 修改日志完整记录频率 日志完整记录频率默认0.01,即千分之一。 取值范围0~1,0为完全不记录,1为100%记录。 pamirs: eip: log: frequency: 0.01 临时开启某接口日志完整记录 在“集成接口”应用中,可临时针对某一接口开启完整日志记录功能,此功能适用于集成接口与开放接口。 在“集成设计器”中也支持此功能。 注意事项 请求失败的接口不会受到配置的影响,日志内容将被完整记录。

    2024年10月8日
    1.2K00
  • 4.7.3版本升级说明-20240115

    版本号:4.7.x发布日期:2024.01.15更新要点:提高多语言翻译功能/改进工作流执行参数的转换逻辑/解决上个版本中存在的问题 ,请及时更新。 4.7.x版本 升级内容说明 增强国际化翻译能力 优化工作流执行参数转化逻辑 协同开发的支持,使用参考:https://doc.oinone.top/backend/4821.html 4.6.x所有的优化点 平台jar包版本 <!–平台基础jar包–> <pamirs.middleware.version>4.7.0</pamirs.middleware.version> <pamirs.k2.version>4.7.3.1</pamirs.k2.version> <pamirs.boot.version>4.7.7.3</pamirs.boot.version> <pamirs.framework.version>4.7.5.2</pamirs.framework.version> <pamirs.core.version>4.7.7.2</pamirs.core.version> <pamirs.distribution.version>4.7.4.1</pamirs.distribution.version> <pamirs.metadata.manager>4.7.3</pamirs.metadata.manager> <pamirs.lowcode.version>4.7.0</pamirs.lowcode.version> <!–设计器jar包–> <pamirs.designer.common.version>4.7.2</pamirs.designer.common.version> <pamirs.workflow.version>4.7.6.6</pamirs.workflow.version> <pamirs.flow.designer.base.version>4.7.3</pamirs.flow.designer.base.version> <pamirs.dataflow.designer.version>4.7.0</pamirs.dataflow.designer.version> <pamirs.workflow.designer.version>4.7.2</pamirs.workflow.designer.version> <pamirs.workbench.version>4.7.1</pamirs.workbench.version> <pamirs.model.designer.version>4.7.1</pamirs.model.designer.version> <pamirs.ui.designer.version>4.7.4</pamirs.ui.designer.version> <pamirs.data.designer.version>4.7.0</pamirs.data.designer.version> <pamirs.data.visualization.version>4.7.1</pamirs.data.visualization.version> <pamirs.eip.designer.version>4.7.0</pamirs.eip.designer.version> docker镜像版本 harbor.oinone.top/oinone/designer:4.7.10.4-allinone-mini 仅包含前后端工程harbor.oinone.top/oinone/designer-backend:latest 仅包含后端工程 RSQL相关的几个Java类路径调整 pro.shushi.pamirs.core.common.rsql.RSQLHelper; pro.shushi.pamirs.core.common.rsql.RSQLNodeInfo; pro.shushi.pamirs.core.common.rsql.connector.RSQLNodeConnector; pro.shushi.pamirs.core.common.entry.TreeNode; 替换为: pro.shushi.pamirs.framework.gateways.rsql.RSQLHelper; pro.shushi.pamirs.framework.gateways.rsql.RSQLNodeInfo; pro.shushi.pamirs.framework.gateways.rsql.connector.RSQLNodeConnector; pro.shushi.pamirs.framework.common.entry.TreeNode; 工作流回调钩子 注: 新版业务数据存在不兼容老版的情况,老版工作流流程数据运行完成之后升级新版 原有业务中使用工作流 fallBack、recall、 reject 钩子,函数接收String字符串后转换成对象简化。 @Function(summary = "回调方法") @Function.Advanced(displayName = "回调方法") public 业务模型 fallBack/recall/reject(String data) { 业务模型 proxy = JsonUtils.parseObject(data, new TypeReference<业务模型>(){}); // … 业务操作 return proxy; } 如果您有任何问题、建议或反馈,请随时联系我们。为了获得最佳体验,请升级至最新版本。我们将继续努力改进产品,提供更好的服务。谢谢!

    2023年12月1日
    1.5K00
  • 4.1.24 框架之分库分表

    随着数据库技术的发展如分区设计、分布式数据库等,业务层的分库分表的技术终将成老一辈程序员的回忆,谈笑间扯扯蛋既羡慕又自吹地说到“现在的研发真简单,连分库分表都不需要考虑了”。竟然这样为什么要写这篇文章呢?因为现今的数据库虽能解决大部分场景的数据量问题,但涉及核心业务数据真到过亿数据后性能加速降低,能给的方案都还有一定的局限性,或者说性价比不高。相对性价比比较高的分库分表,也会是现阶段一种不错的补充。言归正传oinone的分库分表方案是基于Sharding-JDBC的整合方案,所以大家得先具备一点Sharding-JDBC的知识。 一、分表(举例) 做分库分表前,大家要有一个明确注意的点就是分表字段的选择,它是非常重要的,与业务场景非常相关。在明确了分库分表字段以后,甚至在功能上都要做一些妥协。比如分库分表字段在查询管理中做为查询条件是必须带上的,不然效率只会更低。 Step1 新建ShardingModel模型 ShardingModel模型是用于分表测试的模型,我们选定userId作为分表字段。分表字段不允许更新,所以这里更新策略设置类永不更新,并在设置了在页面修改的时候为readonly package pro.shushi.pamirs.demo.api.model; import pro.shushi.pamirs.boot.base.ux.annotation.field.UxWidget; import pro.shushi.pamirs.boot.base.ux.annotation.view.UxForm; import pro.shushi.pamirs.meta.annotation.Field; import pro.shushi.pamirs.meta.annotation.Model; import pro.shushi.pamirs.meta.enmu.FieldStrategyEnum; @Model.model(ShardingModel.MODEL_MODEL) @Model(displayName = "分表模型",summary="分表模型",labelFields ={"name"} ) public class ShardingModel extends AbstractDemoIdModel { public static final String MODEL_MODEL="demo.ShardingModel"; @Field(displayName = "名称") private String name; @Field(displayName = "用户id",summary = "分表字段",immutable=true/* 不可修改 **/) @UxForm.FieldWidget(@UxWidget(readonly = "scene == 'redirectUpdatePage'"/* 在编辑页面只读 **/ )) @Field.Advanced(updateStrategy = FieldStrategyEnum.NEVER) private Long userId; } 图4-1-24-1 新建ShardingModel模型 Step2 配置分表策略 配置ShardingModel模型走分库分表的数据源pamirsSharding 为pamirsSharding配置数据源以及sharding规则 a. pamirs.sharding.define用于oinone的数据库表创建用 b. pamirs.sharding.rule用于分表规则配置 pamirs: load: sessionMode: true framework: system: system-ds-key: base system-models: – base.WorkerNode data: default-ds-key: pamirs ds-map: base: base modelDsMap: "[demo.ShardingModel]": pamirsSharding #配置模型对应的库 图4-1-24-2 指定模型对应数据源 pamirs: sharding: define: data-sources: ds: pamirs pamirsSharding: pamirs #申明pamirsSharding库对应的pamirs数据源 models: "[trigger.PamirsSchedule]": tables: 0..13 "[demo.ShardingModel]": tables: 0..7 table-separator: _ rule: pamirsSharding: #配置pamirsSharding库的分库分表规则 actual-ds: – pamirs #申明pamirsSharding库对应的pamirs数据源 sharding-rules: # Configure sharding rule ,以下配置跟sharding-jdbc配置一致 – tables: demo_core_sharding_model: #demo_core_sharding_model表规则配置 actualDataNodes: pamirs.demo_core_sharding_model_${0..7} tableStrategy: standard: shardingColumn: user_id shardingAlgorithmName: table_inline shardingAlgorithms: table_inline: type: INLINE props: algorithm-expression: demo_core_sharding_model_${(Long.valueOf(user_id) % 8)} props: sql.show: true 图4-1-24-3 分库分表规则配置 Step3 配置测试入口 修改DemoMenus类增加一行代码,为测试提供入口 @UxMenu("分表模型")@UxRoute(ShardingModel.MODEL_MODEL) class ShardingModelMenu{} 图4-1-24-4 配置测试入口 Step4 重启看效果 自行尝试增删改查 观察数据库表与数据分布 图4-1-24-5 自行尝试增删改查 图4-1-24-6 观察数据库表与数据分布 二、分库分表(举例) Step1 新建ShardingModel2模型 ShardingModel2模型是用于分库分表测试的模型,我们选定userId作为分表字段。分库分表字段不允许更新,所以这里更新策略设置类永不更新,并在设置了在页面修改的时候为readonly package pro.shushi.pamirs.demo.api.model; import pro.shushi.pamirs.boot.base.ux.annotation.field.UxWidget; import pro.shushi.pamirs.boot.base.ux.annotation.view.UxForm; import…

    2024年5月23日
    1.6K00
  • 5.0.4版本bugfix:修复在某些情况下dubbo服务发布异常的问题,请升级对应版本

    版本号: 5.0.5 版本发布日期:2024.07.12更新要点:修复在某些情况下dubbo服务发布异常的问题 5.0.5 版本 升级说明及步骤(已升级为5.0.0版本忽略) 此版本与4.7.8版本的兼容方案如下,请严格参照升级说明及步骤进行1、【重要】升级前备份base库和用户权限模块所在的库 2、【重要】升级过程执行SQL严格按照升级文档中的步骤执行。特别注意:部分SQL是要求【发布前执行】,部分SQL是要求【发布后执行】 5.0.0升级详细说明及步骤 升级内容(5.0.0) 修复在某些情况下dubbo服务发布异常的问题 修复在某些情况下枚举处理异常的问题 设计器镜像支持将rocketmq改为kafka或rabbitmq 请尽可能保证业务工程前后端服务以及设计器同步升级前端服务仅需重新执行npm install即可自动升级到最新版本 版本包信息 Oinone平台部署及依赖说明(v5.0) 未使用到的版本号请忽略,按项目中使用到的进行替换。 <!– 平台基础 –> <pamirs.middleware.version>5.0.1</pamirs.middleware.version> <pamirs.k2.version>5.0.6</pamirs.k2.version> <pamirs.framework.version>5.0.16</pamirs.framework.version> <pamirs.boot.version>5.0.8</pamirs.boot.version> <pamirs.distribution.version>5.0.3</pamirs.distribution.version> <!– 平台功能 –> <pamirs.metadata.manager>5.0.0</pamirs.metadata.manager> <pamirs.core.version>5.0.26</pamirs.core.version> <pamirs.workflow.version>5.0.6</pamirs.workflow.version> <pamirs.workbench.version>5.0.2</pamirs.workbench.version> <pamirs.data.visualization.version>5.0.1</pamirs.data.visualization.version> <!– 设计器 –> <pamirs.designer.common.version>5.0.1</pamirs.designer.common.version> <pamirs.flow.designer.base.version>5.0.2</pamirs.flow.designer.base.version> <pamirs.workflow.designer.version>5.0.1</pamirs.workflow.designer.version> <pamirs.model.designer.version>5.0.1</pamirs.model.designer.version> <pamirs.ui.designer.version>5.0.7</pamirs.ui.designer.version> <pamirs.data.designer.version>5.0.1</pamirs.data.designer.version> <pamirs.dataflow.designer.version>5.0.2</pamirs.dataflow.designer.version> <pamirs.eip.designer.version>5.0.3</pamirs.eip.designer.version> 注意镜像名称变化 镜像说明 所有镜像均使用docker manifest支持amd64和arm64架构。如镜像拉取过慢,可在对应镜像Tag添加-amd64、-arm64后缀获取单一架构镜像。 docker pull harbor.oinone.top/oinone/oinone-designer-full-v5.0:5.0.5-amd64 docker pull harbor.oinone.top/oinone/oinone-designer-full-v5.0:5.0.5-arm64 镜像拉取 镜像或JAR版本:5.0.5 体验镜像:(所有中间件及前后端服务,包含全部设计器) docker pull harbor.oinone.top/oinone/oinone-designer-full-v5.0:5.0.5 部署镜像:(包含前后端服务,包含全部设计器) docker pull harbor.oinone.top/oinone/oinone-designer-mini-v5.0:5.0.5 流程设计器镜像:(包含前后端服务,仅包含流程设计器) PS:原workflow-designer-standard-v5.0镜像不再提供,请更换为该镜像。 docker pull harbor.oinone.top/oinone/workflow-designer-v5.0:5.0.5 后端镜像:(仅包含后端服务,包含全部设计器) docker pull harbor.oinone.top/oinone/designer-backend-v5.0:5.0.5 前端镜像:(仅包含前端服务,包含全部设计器) PS:前端镜像版本为独立版本,与其他镜像版本不同。原基础镜像为nginx-1.21.0版本,从5.0.7版本开始使用nginx-1.24.0版为基础镜像 docker pull harbor.oinone.top/oinone/designer-frontend-v5.0:5.0.12 独立部署所有设计器JAR:(后端服务,包含所有设计器)pamirs-designer-boot-v5.0-5.0.5.jarpamirs-designer-boot-v5.0-latest.jar 独立部署流程设计器JAR:(后端服务,仅包含流程设计器)pamirs-workflow-designer-boot-v5.0-5.0.5.jarpamirs-workflow-designer-boot-v5.0-latest.jar 后端无代码设计器Jar包启动方法 如果您有任何问题、建议或反馈,请随时联系我们。为了获得最佳体验,请及时更新至最新版本。我们将继续努力改进产品,提供更好的服务。谢谢!

    2024年7月12日
    1.5K00

Leave a Reply

Please Login to Comment