深度分页问题优化方案

问题原因

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

相关推荐

  • 【界面设计器】自定义字段组件实战——表格字段内嵌表格

    阅读之前 此文章为实战教程,已假定你熟悉了【界面设计器】较为完整的【自定义组件】相关内容。 如果在阅读过程中出现的部分概念无法理解,请自行学习相关内容。【前端】文章目录 业务背景 表格中的一对多(O2M)或多对多(M2M)字段使用表格展开。 演示内容:在【商品】的表格中存在【库存信息】这一列,这一列的内容通过表格展示【尺码】和【数量】两列。 业务分析及实现思路 从需求来看,我们需要实现一个【内嵌表格】组件,并且该组件允许在【表格】视图中使用。与之前不同的是,这里我们需要支持两个业务类型一对多(O2M)和多对多(M2M),即一个组件中包含两个元件。 在【内嵌表格】组件的属性面板中,我们需要再定义一个【内嵌表格配置】组件,用来选择内嵌表格中需要哪些字段进行组合,以及为每个组合提供一些基础配置。 这里需要理解一个基本概念,即【内嵌表格】的属性面板是【内嵌表格配置】的【执行页面】。所有组件的属性面板在【执行页面】时都是【表单】视图。 因此我们可以实现一个【内嵌表格配置】组件,并且该组件允许在【表单】视图中使用。其业务类型使用【文本】,我们在保存配置数据时,可以使用JSON数据结构来存储复杂结构。(这里的实现思路并非是最符合协议设定的,但可以满足绝大多数组件场景) 在【内嵌表格配置】组件中,我们可以允许用户添加/移除组合,并且每个组合有两个属性,【标题】和【字段】。 一些解释 看过【界面设计器】自定义字段组件实战——表格字段组合展示文章的读者可能很熟悉这一实现思路,会想当然的尝试将两个组件进行合并。这里我觉得有必要作出一些实现思路上的解释。 虽然在表面上看起来【组合列配置】和【内嵌表格配置】用到的属性完全一样,但在实现上,由于关联关系的查询需要在组件中特殊处理【透出字段(选项字段列表)】字段(【界面设计器】组件开发常见问题中对该属性进行了解释),才能查询到相应的关联数据。 不仅如此,这两个组件所代表的含义也完全不同。【组合列配置】是在一列中配置需要展示的字段,它在未来可能会增加【颜色(根据条件判断展示不同的颜色)】、【动作(可点击的行为)】等等诸多与之相关的属性。【内嵌表格配置】是在一列中配置表格中的多列,它在未来可能会增加【行高(控制表格行高)】、【支持排序(表格列支持排序)】等等诸多与之相关的属性。 在这里希望读者可以理解一点:相似并不代表相关。组件的抽象与归纳整理的不同点在于,抽象更需要关心其本身所代表的含义,而不是仅关注其相似程度。将多个相似度高但含义不同的组件进行归纳整理得到的只是一个含义不明,无法适应变化的组件。 因此,我们仍然使用两个不同的组件进行实现。 准备工作 此处你应该已经准备好了【商品】和【库存】两个模型,并且可以完整执行【商品】模型的全部【增删改查】操作。 业务模型定义(此处模型定义并非业务中正常使用的模型定义,仅作为演示使用) (以下仅展示本文章用到的模型字段,忽略其他无关字段。) 关联字段:-左侧表示当前模型中的字段API名称,右侧表示关联模型中的字段API名称。 商品(Item) 名称 API名称 业务类型 是否多值 长度(单值长度) 关联模型 关联字段 ID id 整数 否 – – – 编码 code 文本 否 128 – – 名称 name 文本 否 128 – – 库存信息 inventoryInfo 一对多 是 – 库存(Inventory) id – itemId 库存(Inventory) 名称 API名称 业务类型 是否多值 长度(单值长度) 关联模型 关联字段 ID id 整数 否 128 – – 商品 item 多对一 否 – 商品(Item) itemId – id 商品ID itemId 整数 否 – – – 尺码 size 文本 否 128 – – 库存 count 整数 否 – – – PS:如果是使用【模型设计器】创建这两个模型,在创建关联关系字段时必须使用双向关联,才能正确建立关联关系。 实现页面效果展示 表格视图 表单视图 库存信息配置 创建组件、元件 准备工作完成后,我们需要根据【业务背景】确定【组件】以及【元件】相关信息,并在【界面设计器】中进行创建。 以下操作过程将省略详细步骤,仅展示可能需要确认的关键页面。 创建内嵌表格组件 创建内嵌表格元件(一对多) 创建内嵌表格元件(多对多) 创建内嵌表格配置组件 创建内嵌表格配置元件 设计内嵌表格元件属性面板 (两个元件的属性面板可以完全一致) 创建tableConfig字段,并切换至【内嵌表格配置】组件。 再拖入【透出字段(选项字段列表)】,并设置为隐藏。 设计内嵌表格配置元件属性面板 启动SDK工程进行组件基本功能开发 开发步骤参考 打开【表格】视图,将【库存信息】字段的组件切换为【内嵌表格】 在属性面板中看到【内嵌表格配置】组件,并优先实现【内嵌表格配置】组件。这里的属性面板就是【内嵌表格配置】组件对应的【执行页面】。 当【内嵌表格配置】组件可以按照预先设计的数据结构正确保存tableConfig属性时,可以在【内嵌表格】组件中的props定义中直接获取该属性,接下来就可以进行【内嵌表格】组件的开发。 代码实现参考 工程结构 typing.ts export interface InlineTableConfig { key: string; label?: string; field?: string; } FieldService.ts import { GenericFunctionService, IModelField, QueryPageResult } from '@kunlun/dependencies'; export class FieldService { private static readonly FIELD_MODEL = 'base.Field'; public static async fetchFieldsByModel(model: string, filter?: string): Promise<IModelField[]> { let rsql = `model == "${model}"`; if (filter) {…

    2023年11月1日
    1.9K00
  • 如何自定义 GraphQL 请求

    在开发过程中,有时需要自定义 GraphQL 请求来实现更灵活的数据查询和操作。本文将介绍两种主要的自定义 GraphQL 请求方式:手写 GraphQL 请求和调用平台 API。 方式一:手写 GraphQL 请求 手写 GraphQL 请求是一种直接编写查询或变更语句的方式,适用于更复杂或特定的业务需求。以下分别是 query 和 mutation 请求的示例。 1. 手写 Query 请求 以下是一个自定义 query 请求的示例,用于查询某个资源的语言信息列表。 const customQuery = async () => { const query = `{ resourceLangQuery { queryListByEntity(query: {active: ACTIVE, installState: true}) { id name active installState code isoCode } } }`; const result = await http.query('resource', query); this.list = result.data['resourceLangQuery']['queryListByEntity']; }; 说明: query 语句定义了一个请求,查询 resourceLangQuery 下的语言信息。 查询的条件是 active 和 installState,只返回符合条件的结果。 查询结果包括 id、name、active、installState 等字段。 2. 手写 Mutation 请求 以下是一个 mutation 请求的示例,用于创建新的资源分类信息。 const customMutation = async () => { const code = Date.now() const name = `测试${code}` const mutation = `mutation { resourceTaxKindMutation { create(data: {code: "${code}", name: "${name}"}) { id code name createDate writeDate createUid writeUid } } }`; const res = await http.mutate('resource', mutation); console.log(res); }; 说明: mutation 语句用于创建一个新的资源分类。 create 操作的参数是一个对象,包含 code 和 name 字段。 返回值包括 id、createDate 等字段。 方式二:调用平台的 API 平台 API 提供了简化的 GraphQL 调用方法,可以通过封装的函数来发送 query 和 mutation 请求。这种方式减少了手写 GraphQL 语句的复杂性,更加简洁和易于维护。 1. 调用平台的 Mutation API 使用平台的 customMutation 方法可以简化 Mutation 请求。 /** * 自定义请求方法 * @param modelModel 模型编码 * @param method 方法名或方法对象 * @param records 请求参数,可以是单体对象或者对象的列表 * @param requestFields…

    2024年9月21日
    2.3K00
  • 如何设计公用跳转动作(类似导入导出动作)

    背景 设计一个公共动作,在界面设计器可以拖到页面里,点击之后跳转指定页面。就像导入导出一样。 实现思路 元数据计算时,初始化跳转动作,为本模块以及依赖于本模块的所有模块生成该跳转动作。实现所有模型都有该跳转动作的元数据。 代码示例: package pro.shushi.pamirs.top.core.init; import com.google.common.collect.Lists; import org.apache.commons.collections4.MapUtils; import org.springframework.stereotype.Component; import pro.shushi.pamirs.boot.base.enmu.ActionTargetEnum; import pro.shushi.pamirs.boot.base.enmu.ActionTypeEnum; import pro.shushi.pamirs.boot.base.model.ViewAction; import pro.shushi.pamirs.boot.common.api.command.AppLifecycleCommand; import pro.shushi.pamirs.boot.common.extend.MetaDataEditor; import pro.shushi.pamirs.core.common.InitializationUtil; import pro.shushi.pamirs.meta.annotation.fun.extern.Slf4j; import pro.shushi.pamirs.meta.api.dto.meta.Meta; import pro.shushi.pamirs.meta.api.dto.meta.MetaData; import pro.shushi.pamirs.meta.domain.model.ModelDefinition; import pro.shushi.pamirs.meta.enmu.ActionContextTypeEnum; import pro.shushi.pamirs.meta.enmu.SystemSourceEnum; import pro.shushi.pamirs.meta.enmu.ViewTypeEnum; import pro.shushi.pamirs.top.api.TopModule; import pro.shushi.pamirs.top.api.model.Teacher; import java.util.*; import java.util.stream.Collectors; @Slf4j @Component public class DemoModuleAppInstall implements MetaDataEditor { @Override public void edit(AppLifecycleCommand command, Map<String, Meta> metaMap) { InitializationUtil util = InitializationUtil.get(metaMap, TopModule.MODULE_MODULE, TopModule.MODULE_NAME); if (util == null) { return; } if (MapUtils.isEmpty(metaMap)) { return; } Set<String> dependencyFileModels = metaMap.values().stream() .filter(v -> v.getData().containsKey(TopModule.MODULE_MODULE)) .map(Meta::getModule) .collect(Collectors.toSet()); for (String module : metaMap.keySet()) { if (!dependencyFileModels.contains(module)) { // 不依赖本模块,不生成跳转动作 continue; } Meta meta = metaMap.get(module); MetaData metaData = meta.getCurrentModuleData(); List<ModelDefinition> modelList = metaData.getDataList(ModelDefinition.MODEL_MODEL); for (ModelDefinition data : modelList) { makeDefaultModelViewAction(meta, data, dependencyFileModels); } } } // 跳转的xml模版 name public static final String DEFAULT_VIEW_NAME = "fixed_teacher_table"; private void makeDefaultModelViewAction(Meta meta, ModelDefinition data, Set<String> dependencyFileModels) { if (!dependencyFileModels.contains(data.getModule())) { // 当前模块使用了其他模块的模型,对方模块未依赖本模块,不生成跳转动作 return; } Map<String, Object> context = new HashMap<>(); context.put("model", "'" + data.getModel() + "'"); // 创建 跳转表格页面 viewAction,根据实际需求更改 makeDefaultViewAction(meta, data, "teacherListDialog", "教师表格", null, ActionContextTypeEnum.CONTEXT_FREE, ViewTypeEnum.TABLE, 99, Teacher.MODEL_MODEL, DEFAULT_VIEW_NAME,…

    2025年10月22日
    81300
  • Oinone协同开发使用手册

    概述 Oinone平台为开发人员提供了本地环境 – 测试环境之间的协同开发模式,可以使得开发人员在本地环境中设计的模型、函数等元数据实时被测试环境使用并设计。开发人员开发完成对应页面和功能后,可以部署至测试环境直接进行测试。 本篇文章将详细介绍协同开发模式在实际开发中的应用及相关内容。 名词解释 本地环境: 开发人员的本地启动环境 测试环境: 在测试服务器上部署的业务测试环境,业务工程服务和设计器服务共用中间件 业务工程服务:在测试服务器上部署的业务工程 设计器服务: 在测试服务器上部署的设计器镜像 一套环境:以测试环境为例,业务工程服务和设计器服务共同组成一套环境 生产环境: 在生产服务器上部署的业务生产环境 环境准备 部署了一个可用的设计器服务,并能正常访问。(需参照下文启动设计器环境内容进行相应修改) 准备一个用于开发的java工程。 准备一个用于部署测试环境的服务器。 协同参数介绍 用于测试环境的参数 -PmetaProtected=${value} 启用元数据保护,只有配置相同启动参数的服务才允许对元数据进行更新。通常该命令用于设计器服务和业务工程服务,并且两个环境需使用相同的元数据保护标记(value)进行启动。本地环境不使用该命令,以防止本地环境在协同开发时意外修改测试环境元数据,导致元数据混乱。 用法 java -jar boot.jar -PmetaProtected=pamirs 用于本地环境的配置 使用命令配置ownSign(推荐) java -jar boot.jar –pamirs.distribution.session.ownSign=demo 使用yaml配置ownSign pamirs: distribution: session: allMetaRefresh: false # 启用元数据全量刷新(备用配置,如遇元数据错误或混乱,启用该配置可进行恢复,使用一次后关闭即可) ownSign: demo # 协同开发元数据隔离标记,用于区分不同开发人员的本地环境,其他环境不允许使用 启动设计器环境 docker-run启动 -e PROGRAM_ARGS=-PmetaProtected=pamirs docker-compose启动 services: backend: container_name: designer-backend image: harbor.oinone.top/oinone/designer-backend-v5.0 restart: always environment: # 指定spring.profiles.active ARG_ENV: dev # 指定-Plifecycle ARG_LIFECYCLE: INSTALL # jvm参数 JVM_OPTIONS: "" # 程序参数 PROGRAM_ARGS: "-PmetaProtected=pamirs" PS: java [JVM_OPTIONS?] -jar boot.jar [PROGRAM_ARGS?] 开发流程示例图 具体使用步骤详见协同开发支持

    2024年7月24日
    2.9K00
  • 正式版发布:Oinone 6.0.0 版本 新增涡轮增压加速启动,邀您体验

    版本号: 6.0.0 版本发布日期:2025.03.17更新要点:新增涡轮增压加速启动 6.0.0 版本 启动工程关于pamirs包的扫描顺序需要进行修复 @ComponentScan( basePackages = { "pro.shushi.pamirs", } ) 20250418升级内容 镜像版本升级: 6.0.1.4 –> 6.0.2 前端版本升级 后端版本升级:6.0.1.6 –> 6.0.2 修复跨模块追加函数或模块重载时导致未启动模块元数据丢失的问题 修复登录页面语言与登录后不一致的问题 20250407升级内容 镜像版本升级: 6.0.1.3 –> 6.0.1.4 后端版本升级: 6.0.1.5 –> 6.0.1.6 修复无界面设计器环境下,标品安装元数据时因自定义组件导致的启动报错或自定义组件不生效问题 修复界面设计器部分服务无法远程调用的问题 同步更新5.7.x-20250328版本升级内容 修复在某些特殊情况下启动时,首页元数据保存错误的问题 修复界面设计器在2023年3月之前的视图无法正常发布的问题 20250326升级内容 镜像版本升级: 6.0.0.1 –> 6.0.1.3 前端版本升级 后端版本升级:6.0.1.2 –> 6.0.1.5 新增调试工具返回服务端日志的功能 修复在特殊情况下发生Class.forName死锁的问题 20250325升级内容 镜像版本升级: 6.0.0.1 –> 6.0.1.1 前端版本升级 后端版本升级:6.0.1.2 支持URL动态配置 URL动作支持计算函数 字段添加属性-字段动作配置 表格的优化。允许进行新增/复制一行等操作 表格列自动调节宽度 表单、详情动作区动作可以固定。 优化分布式持久化内存大小(内存占用约减少30%以上) 同步更新5.7.x-20250320版本升级内容 修复启动初始化Bean顺序导致空指针的问题 修复模块依赖转换错误的问题 修复跨模块继承元数据在包含jar包依赖时计算错误的问题 移除对无代码模块自动生成视图的支持 修复URL链接动作元数据无法填充compute的问题 修复工作流审批详情获取数据错误的问题 支持退回流程上文中任意人工节点 业务流程、工作流详情, 自定义审批人信息补充 修复界面设计器保存菜单时导致元数据反解析错误的问题 升级内容(6.0.0) 新增涡轮增压加速启动(启动速度约提升30%以上) 业务工程新增依赖项 <dependency> <groupId>pro.shushi.pamirs.framework</groupId> <artifactId>pamirs-framework-turbo</artifactId> </dependency> 请尽可能保证业务工程前后端服务以及设计器同步升级前端服务仅需重新执行npm run clean && npm install即可自动升级到最新版本 后端版本包信息 Oinone平台部署及依赖说明(v5.3) 未使用到的版本号请忽略,按项目中使用到的进行替换。 <!– 平台基础 –> <oinone.version>6.0.2</oinone.version> <!– 设计器 –> <pamirs.workflow.designer.version>6.0.0</pamirs.workflow.designer.version> <pamirs.model.designer.version>6.0.1</pamirs.model.designer.version> <pamirs.ui.designer.version>6.0.2</pamirs.ui.designer.version> <pamirs.print.designer.version>6.0.0</pamirs.print.designer.version> <pamirs.data.designer.version>6.0.1</pamirs.data.designer.version> <pamirs.dataflow.designer.version>6.0.0</pamirs.dataflow.designer.version> <pamirs.eip.designer.version>6.0.2</pamirs.eip.designer.version> <pamirs.microflow.designer.version>6.0.0</pamirs.microflow.designer.version> <dependencyManagement> <dependencies> <dependency> <groupId>pro.shushi</groupId> <artifactId>oinone-bom</artifactId> <version>${oinone.version}</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> oinone-bom详细版本信息 <!– 平台基础 –> <pamirs.middleware.version>6.0.0</pamirs.middleware.version> <pamirs.k2.version>6.0.4</pamirs.k2.version> <pamirs.framework.version>6.0.8</pamirs.framework.version> <pamirs.boot.version>6.0.6</pamirs.boot.version> <pamirs.distribution.version>6.0.4</pamirs.distribution.version> <!– 平台功能 –> <pamirs.metadata.manager>6.0.0</pamirs.metadata.manager> <pamirs.designer.metadata.version>6.0.1</pamirs.designer.metadata.version> <pamirs.core.version>6.0.7</pamirs.core.version> <pamirs.workflow.version>6.0.3</pamirs.workflow.version> <pamirs.workbench.version>6.0.1</pamirs.workbench.version> <pamirs.data.visualization.version>6.0.1</pamirs.data.visualization.version> <!– 设计器 –> <pamirs.designer.common.version>6.0.1</pamirs.designer.common.version> <pamirs.flow.designer.base.version>6.0.2</pamirs.flow.designer.base.version> 前端版本包信息 { "@kunlun/dependencies": "6.0.3", "@kunlun/vue-ui-antd": "6.0.3", "@kunlun/vue-ui-el": "6.0.3", "@kunlun/mobile-dependencies": "6.0.0", "@kunlun/vue-ui-mobile-vant": "6.0.0", "@kunlun/mobile-workbench": "6.0.0", "@kunlun/data-designer-open-pc": "6.0.0", "@kunlun/data-designer-open-mobile": "6.0.0" } 前端详细版本信息 可通过node_modules/@kunlun查看 { "@kunlun/cache": "6.0.0", "@kunlun/dsl": "6.0.0", "@kunlun/environment": "6.0.0", "@kunlun/event": "6.0.0", "@kunlun/expression": "6.0.0", "@kunlun/meta": "6.0.0", "@kunlun/request": "6.0.0", "@kunlun/router": "6.0.0", "@kunlun/service": "6.0.0", "@kunlun/shared":…

    2025年3月17日
    1.4K00

Leave a Reply

Please Login to Comment