深度分页问题优化方案

问题原因

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

相关推荐

  • 5.1.0版本feature:新增用户会话配置项,请升级对应版本

    版本号: 5.1.13 版本发布日期:2024.09.18更新要点:新增用户会话配置项 5.1.13 版本 升级说明及步骤(已升级为5.0.0版本忽略) 此版本与4.7.8版本的兼容方案如下,请严格参照升级说明及步骤进行1、【重要】升级前备份base库和用户权限模块所在的库 2、【重要】升级过程执行SQL严格按照升级文档中的步骤执行。特别注意:部分SQL是要求【发布前执行】,部分SQL是要求【发布后执行】 5.0.0升级详细说明及步骤 升级内容(5.1.0) 新增用户会话配置项 修复用户会话过期时间续约的问题 修复时间范围组件打开后选中的时间为当前时间 修复表达式计算含有小数点的金额错误 修复权限组名称长度从128到256 修复Excel模板初始化异常的问题 修复EIP验证AccessToken过期时效的问题 修复字段权限【全部】未生效的问题 pamirs: user: # 超级管理员默认配置,仅首次启动时生效 admin: # 登录名 login: admin # 默认密码 password: admin # 默认昵称 name: 超级管理员 session: # 用户会话模式(使用其他值可自定义会话模式:pro.shushi.pamirs.user.api.spi.UserCacheApi) # 单用户会话(single):一个用户仅可以在一个浏览器登录,后登录的用户会强制先登录的用户下线。 # 多用户会话(multiple):一个用户可以在多个浏览器登录,不限会话数量。 mode: multiple # 用户会话过期时间;单位:秒; expire: 7200 # 2个小时后过期 # 用户会话续约时间;单位:秒;(建议续约时间小于等于会话过期时间) renewed-expire: 7200 # 每次操作续约2个小时 # 用户会话续约过滤URL;指定请求被接收时,不进行续约; renewed-filter-urls: – /pamirs/message # 内置过滤URL,无需配置,不可移除。 请尽可能保证业务工程前后端服务以及设计器同步升级前端服务仅需重新执行npm install即可自动升级到最新版本 版本包信息 Oinone平台部署及依赖说明(v5.0) 未使用到的版本号请忽略,按项目中使用到的进行替换。 <!– 平台基础 –> <pamirs.middleware.version>5.0.3</pamirs.middleware.version> <pamirs.k2.version>5.1.7</pamirs.k2.version> <pamirs.framework.version>5.1.13</pamirs.framework.version> <pamirs.boot.version>5.1.8</pamirs.boot.version> <pamirs.distribution.version>5.1.7</pamirs.distribution.version> <!– 平台功能 –> <pamirs.metadata.manager>5.1.2</pamirs.metadata.manager> <pamirs.designer.metadata.version>5.1.3</pamirs.designer.metadata.version> <pamirs.core.version>5.1.20</pamirs.core.version> <pamirs.workflow.version>5.1.8</pamirs.workflow.version> <pamirs.workbench.version>5.1.0</pamirs.workbench.version> <pamirs.data.visualization.version>5.1.3</pamirs.data.visualization.version> <!– 设计器 –> <pamirs.designer.common.version>5.1.2</pamirs.designer.common.version> <pamirs.flow.designer.base.version>5.1.3</pamirs.flow.designer.base.version> <pamirs.workflow.designer.version>5.1.2</pamirs.workflow.designer.version> <pamirs.model.designer.version>5.1.4</pamirs.model.designer.version> <pamirs.ui.designer.version>5.1.9</pamirs.ui.designer.version> <pamirs.data.designer.version>5.1.2</pamirs.data.designer.version> <pamirs.dataflow.designer.version>5.1.1</pamirs.dataflow.designer.version> <pamirs.eip.designer.version>5.1.2</pamirs.eip.designer.version> 注意镜像名称变化 镜像说明 所有镜像均使用docker manifest支持amd64和arm64架构。如镜像拉取过慢,可在对应镜像Tag添加-amd64、-arm64后缀获取单一架构镜像。 docker pull harbor.oinone.top/oinone/oinone-designer-full-v5.1:5.1.13.1-amd64 docker pull harbor.oinone.top/oinone/oinone-designer-full-v5.1:5.1.13.1-arm64 镜像拉取 镜像或JAR版本:5.1.13.1 体验镜像:(所有中间件及前后端服务,包含全部设计器) docker pull harbor.oinone.top/oinone/oinone-designer-full-v5.1:5.1.13.1 部署镜像:(包含前后端服务,包含全部设计器) docker pull harbor.oinone.top/oinone/oinone-designer-mini-v5.1:5.1.13.1 流程设计器镜像:(包含前后端服务,仅包含流程设计器) docker pull harbor.oinone.top/oinone/workflow-designer-v5.1:5.1.13.1 后端镜像:(仅包含后端服务,包含全部设计器) docker pull harbor.oinone.top/oinone/designer-backend-v5.1:5.1.13.1 前端镜像:(仅包含前端服务,包含全部设计器) PS:前端镜像版本为独立版本,与其他镜像版本不同。原基础镜像为nginx-1.21.0版本,从5.0.7版本开始使用nginx-1.24.0版为基础镜像 docker pull harbor.oinone.top/oinone/designer-frontend-v5.1:5.1.19 独立部署所有设计器JAR:(后端服务,包含所有设计器)pamirs-designer-boot-v5.1-5.1.13.1.jarpamirs-designer-boot-v5.1-latest.jar 独立部署流程设计器JAR:(后端服务,仅包含流程设计器)pamirs-workflow-designer-boot-v5.1-5.1.13.1.jarpamirs-workflow-designer-boot-v5.1-latest.jar 后端无代码设计器Jar包启动方法 如果您有任何问题、建议或反馈,请随时联系我们。为了获得最佳体验,请及时更新至最新版本。我们将继续努力改进产品,提供更好的服务。谢谢!

    2024年9月18日
    1.3K00
  • 管理中心

    管理中心由原「合作伙伴中心」「用户中心」「权限」3部分构成。

    2024年8月29日
    1.4K00
  • 【界面设计器】左树右表

    阅读之前 你应该: 熟悉模型的增删改查相关内容。【界面设计器】模型增删改查基础 名词解释 主体:在视图中提供数据源的主要组件,并且所有动作都围绕着该主体展开。 一级搜索:在表格视图中,上方直观可见的搜索区,为表格提供筛选功能。 二级搜索:与一级搜索不同的是,其搜索条件是通过某些组件的行为追加到一级搜索条件之上的筛选功能。 概述 平台中对于左树右表提供了两种类型的展示形式。 在表格视图中的左树右表,是以表格为主体,树组件为表格提供了二级搜索功能。选中树节点时将对表格追加节点的搜索条件,并重新执行查询。 在树视图中,是以树为主体,其展开的视图可以是表格、表单、详情等其他视图。 PS:不论是树、级联这些视图组件,还是树选择、级联这些字段组件,其配置数据结构的方式是不尽相同的。唯一的区别在于最终到达的目标模型来源不同。 场景1 为了方便接下来的描述,我们需要先构建一个基本的业务场景,这个场景中包含【商品】和【商品类目】两个模型。 在【商品】的表格左侧添加【商品类目】树,选择某个商品类目后,可以根据商品类目进行筛选,查询所属类目下的全部商品。 其中【商品类目】使用【卡片级联】的展示方式进行管理。 其模型定义如下: 商品(Item) 名称 API名称 业务类型 是否多值 长度(单值长度) 关联模型 关联字段 ID id 整数 否 – – – – 编码 code 文本 否 128 – – – 名称 name 文本 否 128 – – 所属类目 category 多对一 否 – 商品类目(ItemCategory) categoryId – id 所属类目ID categoryId 整数 否 – – – 商品类目(ItemCategory) 名称 API名称 业务类型 是否多值 长度(单值长度) 关联模型 关联字段 ID id 整数 否 128 – – 编码 code 文本 否 128 – – – 名称 name 文本 否 128 – – 上级类目 parent 多对一 是 – 商品类目(ItemCategory) parentId – id 上级类目ID parentId 整数 否 – – – PS:实际业务场景中,【商品类目】通常使用编码进行关联,即parentCode – code;不仅如此,通常还会添加treeCode字段,以此来实现高效查询当前节点的所有子节点的能力。在演示模型中,我们不必关注这些内容。 创建【商品】视图 设置联动关系 这里我们需要配置的是【商品类目】的树结构,因此,在【第1级关联】中的模型选择【商品类目】。 在【商品类目】中是通过【上级类目】进行的自关联,因此,在【第1级关联】中的【自关联关系字段】选择【上级类目】。 在选中【商品类目】节点后,需要对右侧表格发起查询。其筛选条件是通过【商品】中的【所属类目】进行筛选的。因此,在【第1级关联】中的【表格关联关系字段】选择【所属类目】。那么,在表格发起查询前,会根据【所属类目】字段的关联关系配置自动添加筛选条件。 配置如下图所示: 创建【商品类目】视图 设置联动关系 这里我们需要配置的是【商品类目】的树结构(级联只是树结构的另一种表现形式) 细心的同学可能发现这里没有【表格关联关系字段】,因此,我们仅需配置【自关联关系字段】即可。 配置如下图所示: 为【商品类目】添加增删改查基础功能 与表格视图不同的是,行内动作区被放在了第一个卡片中的动作区,其他配置方式完全一致。 在这里需要理解的是,一个树节点对应的是表格中的一行。 【商品类目】使用展开视图进行编辑(可选) 打开【支持展开视图】开关,并设置展开视图。这里我们用表单视图进行编辑操作。 和其他表单一样,我们将必要的字段和动作拖入对应区域即可。 由于展开视图只会在选中节点时出现,因此我们仅需提供更新功能即可。 这里需要注意: 提交动作默认打开了【返回上一页】的功能,在当前场景中,更新动作提交数据后,没有上一页需要返回,因此需要关闭【返回上一页】的开关。 提交动作默认打开了【刷新当前视图】的功能,在当前场景中,更新按钮处于【展开视图】中,仅刷新当前视图是不够的,当数据发生变更时,我们需要将级联组件一并刷新,因此需要打开【刷新主视图】的开关。 PS:【编辑】动作和【展开视图编辑】功能是重复的,在使用时应该只选择其中一种。 【商品类目】限制仅支持四级,并为每一个卡片添加标题(可选) 移除【第1级关联】中的【自关联关系字段】,依次添加2、3、4级关联,选择【商品类目】模型,将自动选中【层级关联关系字段】为【上级类目】,并输入每一级关联的标题即可。 这里需要注意的是,在【第1级关联】中需要添加筛选条件,使其只能查询到根节点。 PS:这里的限制仅为交互上的限制,在创建/更新时,如果可以在服务端限制上级类目的选择,以及数据提交时的校验,效果更佳。 【商品类目】的【创建/编辑】使用弹窗打开(可选) 有时我们希望用户在页面中的操作尽可能的流畅,在表单规模较小的情况下,我们也可以使用【弹窗/抽屉】这类交互来优化用户体验。 小贴士: 弹窗打开的方式提供三种页面设计模式,绑定已有页面、使用新页面、复制已有页面。 使用新页面和复制已有页面的方式只能进行一次性的视图设计,无法进行复用。 使用绑定已有页面的方式可以使得视图进行复用,但复用的视图也只能同步弹窗的内容部分,弹窗底部的动作仅会在创建动作时复制一次。 跳转动作的打开方式以及页面设计模式等属于元数据信息,无法通过属性面板进行修改,因此只能通过重新创建新动作的方式进行修改。 鉴于业务的复杂和多变,通常情况下我们只采用【绑定已有页面】的方式为弹窗设计内容部分。这样在交互发生变更时,可以更好的适应变化。 场景2 为了方便接下来的描述,我们需要再构建一个基本的业务场景,这个场景中包含【公司】和【部门】两个模型。 【公司】模型的管理能力使用标准的【增删改查】视图。(此处不进行演示) 在【部门】的表格左侧添加【公司】-【部门】树,在选择某个公司后,可以根据所属公司进行筛选,查询所属公司下的全部部门。在选择某个部门后,可以根据上级部门进行筛选,查询该部门下的子部门(不包含子部门的子部门)。 PS:如这里要求查询该部门下的全部子部门,需要服务端配合。 其模型定义如下: 公司(Company) 名称 API名称 业务类型 是否多值 长度(单值长度) 关联模型 关联字段 ID id 整数 否 – – – – 编码 code 文本 否 128 – – – 名称 name 文本…

    2023年11月1日
    4.4K00
  • 界面设计器教程:如何快速完成增删改查

    相关知识点参考 【界面设计器】模型增删改查基础:

    2024年9月30日
    57700
  • 工作流自定义转交/加签人函数执行时机使用说明

    在实际工作流程的应用过程中,我们注意到有小伙伴需要根据当前执行操作的用户,进行筛选转交或加签人员的列表。为了应对这个需求,我们在流程设计器新增了自定义函数执行时机选项。 使用说明 自定义函数执行时机为空时,逻辑同任务创建时生效。 任务创建时生效:当系统创建待办任务时,会立即调用自定义函数确定转交或加签人列表。 功能特性:效率更高,但无法知道当前操作的用户是谁。 潜在影响:如果自定义函数的逻辑被更改,已创建的任务的转交或加签人列表不会受影响。 用户审批时生效:每次用户查看审批或加签人列表时,都会触发自定义函数。 功能特性:可以获取当前操作的用户信息。 潜在影响:如果自定义函数的逻辑更改,转交或加签人列表会根据新逻辑更新。 注意事项:如果自定义函数存在耗时操作,可能会影响用户体验。 使用建议:如果需要获取当前操作的用户,建议使用用户审批时生效。如果自定义函数的运行结果不依赖于操作用户的身份,那么更推荐在任务创建时就执行。

    2024年8月23日
    1.2K00

Leave a Reply

Please Login to Comment