深度分页问题优化方案

问题原因

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

相关推荐

  • 资源

    翻译应用是管理翻译规则的应用,以模型为基础、维护字段的翻译值,支持导入、导出 1. 操作步骤 Step1:导出所有翻译项; Step2:线下翻译; Step3:导入翻译项; Step4:刷新远程资源; Step5:页面右上角可切换语言,查看翻译效果。 2. 新增翻译 翻译是具体到模型字段,其中需要区分出是否字典; 源语言、目标语言,是在资源中维护的语言,可在资源中维护需要翻译的语言; 翻译项则是模型字段,默认翻译项为激活状态,关闭后维护的翻译项无效。 3. 导出、导入 不勾选导出:导出所有需要翻译的翻译项,包括模块、字段,源术语、翻译值等,其中如果已经翻译过的内容,会体现在翻译值中; 勾选导出:导出勾选模型的翻译项。 导入:导入翻译项,平台会根据模型拆分为多条数据。 4. 刷新远程资源 导入翻译项后,点击“刷新远程资源”按钮。 5. 查看翻译内容 页面右上角切换语言,查看翻译效果。

    2024年6月20日
    1.4K00
  • 集成设计器数据流程、流程设计器可以暴露接口触发

    集成设计器数据流程暴露接口触发 需求:在集成设计器配置的连接器、数据流程链接到外部接口,需要可以有一个管理页面,统一管理这些集成配置。比如对接多个医院的挂号系统,希望可以配置好数据流程之后,能够在已经实现的开放接口上,动态的调用集成平台配置的数据流程。 连接器暴露接口触发 设计连接器资源配置模型。使用业务ID+接口唯一标识+连接器实现连接器资源和业务唯一。 @Model.model(EipConnectorResourceSetting.MODEL_MODEL) @Model(displayName = "连接器资源配置", summary = "连接器资源配置") @Model.Advanced(unique = {"hospitalId, interfaceUnique"}) public class EipConnectorResourceSetting extends IdModel { public static final String MODEL_MODEL = "hr.simple.EipConnectorResourceSetting"; @UxTableSearch.FieldWidget(@UxWidget()) @Field(displayName = "医院", required = true) @Field.Relation(relationFields = {"hospitalId"}, referenceFields = {"id"}) private Hospital hospital; @Field.Integer @Field(displayName = "医院ID", invisible = true) private Long hospitalId; @UxTableSearch.FieldWidget(@UxWidget()) @Field.String @Field(displayName = "接口唯一标识", required = true) private String interfaceUnique; @UxTableSearch.FieldWidget(@UxWidget()) @Field.many2one @Field(displayName = "连接器", required = true) @Field.Relation(relationFields = {"connectorId"}, referenceFields = {"id"}) private EipConnector connector; @Field.Integer @Field(displayName = "连接器ID", invisible = true) private Long connectorId; @UxTableSearch.FieldWidget(@UxWidget()) @Field.many2one @Field(displayName = "连接器接口", required = true) @Field.Relation(relationFields = {"integrationInterfaceId"}, referenceFields = {"id"}, domain = "connectorId==${activeRecord.connector.id}") private EipConnectorResource connectorResource; @Field.Integer @Field(displayName = "连接器接口ID", invisible = true) private Long connectorResourceId; } 开放接口定义,文档参考:https://doc.oinone.top/oio4/9326.html外部平台调用开放接口,实现动态调用连接器资源 @Model.model(HospitalSection.MODEL_MODEL) @Model(displayName = "医院科室", summary = "医院科室") public class HospitalSection extends IdModel { public static final String MODEL_MODEL = "net.example.HospitalSection"; @Field(displayName = "科室Code", required = true) private String deptCode; @Field(displayName = "科室名称", required = true) private String deptName; @Field(displayName = "科室描述") private String deptDesc; } @Slf4j @Fun @Component public class TestOpenService { @Resource private TestCommonService testCommonService;…

    2025年4月21日
    88100
  • 总体结构设计示例

    1.项目总体架构 Oinone总体工程架构 Oinone总体项目分层 以常见的B2C和全渠道订单OMS为例分层说明:1、最底层LCDP是低代码开发框架,提供低代码的开发能力;2、CDM通用数据模型层,主要解决系统间的数据标准;3、标品-标准业务产品层, 这层是我们核心的功能层,大部分业务代码都在这里完成;为了达到能按照模块组装的功能,标品需划分好模块,各模块是相对独立的服务(类似微服务的一个服务中心);4、客户定制层,可以对标品某个模块进行扩展,也可以新建模块;对标品扩展方式, 通常有以下几种方式:1)继承标品功能进行扩展2)覆盖方式,重写某个功能3)通过扩展点的方式注入定制逻辑4)通过SPI的方式,替换掉默认逻辑 2、设计器与应用 本地开发环境和开发环境,同一个环境下,有业务应用和设计器的两个入口,需要业务应用和设计器进行实时联动的情况,则要求:1.1 所有的【业务应用】和【设计器】,共用base库和基础数据的库; 业务应用的【业务数据】使用各自的业务库(可多个);1.2 业务应用和设计器之间的互通通过配置网关(如Nginx等)的路由方式; 开发本地或者开发环境,若通过【业务的前端】入口直接访问到设计器,则需在【业务应用】的网关路由配置【设计器】的路由。 开发本地或者开发环境,若通过【设计器的前端】入口直接访问到业务系统,则需在【设计器】的网关路由配置【业务应用】的路由。 1.3 基础应用和业务应用、基础数据和设计器包含在一起,通过指定基础应用模块到对应的数据源的方式实现基础数据共享;1.4 基础应用(文件file/用户权限/资源等)单独部署;业务应用和设计器通过远程方式(RPC)进行调用; 2.1 模式一,应用和基础模块独立 总体方案:1、DB层面每个环境共用base库;主数据(用户、权限、资源等)单独建立主数据库;各自业务系统(包括设计器本身)建立自己的业务库。2、应用层面1)应用和设计器之间通过路由转发的方式相互访问;2)应用单独部署的情况,应用之间通过RPC(Dubbo)的方式进行调用;3)所有的应用AllinOne的方式部署在一起,则直接走SpringBean的方式(Injvm); 2.1.1 模式1,DB划分 2.1.2 模式1,服务调用 2.2 模式二,应用和基础模块合并 3、部署架构图 4、Oinone项目包分层示例 4.1 CDM层示例 CDM层主要定义模型,包括模型之间的关系;对于主数据类的基础服务,可以确定上层不会修改的,也可包含这部分的服务层。 4.2 标品项目示例 ├── pamirs-boot 应用启动模块,启动入口,启动过程中系统性的数据初始化│ │ └── boot 启动类的包路径│ │ └── XxxApplication 模块的应用启动类,遵循spring boot 规范│ │ └── resources/config/application-dev.yml 研发环境的yml配置文件,遵循spring boot 规范│ │ └── resources/bootstrap.yml 启动的yml配置文件,遵循spring boot 规范├── pamirs-common 通用模块 工程通用常量,传输模型,Utils等├── pamirs-major 主数据模块│ ├── pamirs-major-api 对外api包,在此包下定义 模型 服务Service,枚举常量等│ │ └── constant 常量的包路径│ │ └── enums 枚举的包路径│ │ └── model 该领域核心模型的包路径│ │ └── service 该领域对外暴露接口api的包路径│ │ └── tmodel 存放该领域的非存储模型如:用于传输的临时模型│ │ └── MajorModule 该类是Major模块的定义│ ├── pamirs-major-core api的内部逻辑实现包│ │ └── init 模块初始化工作的包路径│ │ └── manager manager是 service的一些公共逻辑,不会定义为独立的function的类│ │ └── service service是对应api工程中service接口的实现类,是模型的function├── pamirs-eip 集成模块│ ├── pamirs-eip-api 对外api包,在此包下定义 模型 服务Service,枚举常量等│ │ └── EipModule 该类是Major模块的定义│ ├── pamirs-eip-core api的内部逻辑实现包├── pamirs-item 商品模块│ ├── pamirs-item-api 对外api包,在此包下定义 模型 服务Service,枚举常量等│ │ └── ItemModule 该类是Major模块的定义│ ├── pamirs-item-core api的内部逻辑实现包│ ├── pamirs-item-view 应用PC端│ │ └── action 模型对外交互的行为的包–对前端页面开放的接口│ │ └── init 模块初始化工作的包路径│ │ └── manager manager是 service的一些公共逻辑,不会定义为独立的function的类 4.3 系统的分层 himalaya(cdm) — himalaya-major — himalaya-common — himalaya-item — himalaya-inventory — himalaya-trade — …… kailas-leo(标品项目) — kailas-leo-major — kailas-leo-item — kailas-leo-trade — kailas-leo-pay — kailas-leo-boot — …… kailas-leo-lb(客户项目)…

    2024年2月20日
    2.0K00
  • 5.1 CDM的背景介绍

    如果说低代码开发框架输出技术标准,CDM则是结合oinone技术特性和软件工程设计,让输出数据标准变成可能。 一、背景介绍 无法照搬的最佳实践 要了解引入CDM的初衷,得从互联网架构的演进开始,了解其过程,就知道为什么说Oinone的CDM是中台架构的最佳技术实践的核心!我们在2.2【互联架构做为最佳实践为何失效】一文中介绍过互联网技术发展的四个阶段,特别平台化到中台化的阶段,目的是在一套规范下让听的见炮火声音的团队自行决定业务系统发展,适用多业务线(或多场景应用)独立发展。 互联网架构在演进过程中碰到的问题跟企业数字化转型过程中碰到的问题是非常类似: 随着企业业务在线化后对系统性能、稳定都提出了更高的要求,而且大部分企业的内部很多系统相互割裂导致,导致很多重复建设,所以我们需要服务化、平台化。 同时没有一个供应商能解决企业所有商业场景问题,又需要多个供应商共同参与,所以把供应商类类比成各个业务线,在一套规范下让供应商自行决定业务系统发展 既然跟阿里当初在架构演进过程中碰到的问题非常类似,那么是不是照搬阿里中台架构方案到企业就好了?当然不是,因为历史原因阿里的中台架构是采用的平台共建模式:“让业务线研发以平台设计好的规范进来共同开发”,其本质还是平台主导模式,它是有非常大的历史包袱。我们想象各个供应商的共建一个交易平台或商品平台,那是多么荒唐的事情,平台化已经足够的复杂了,还让不同背景、不同企业的研发一起共建,最后往往导致企业架构负载过重,这时对企业来说便不再是赋能而是“内耗”。 那么如果没有历史包袱,我们重新设计,站在上帝视角去看有没有更好的方式呢?当然有 借鉴微软的CDM 这里我们借鉴微软的CDM理念,CDM这个概念最早是2016年微软宣布“以Dynamics 365的形式改造其CRM和ERP”战略时提出的。微软给它的定义是“用于存储和管理业务实体的业务数据库,而且是开箱即用的”。CDM不仅仅提供标准实体,它还允许用户建立个性化的实体,用户可以扩展标准实体也可以增加和标准实体相关的新实体。 CDM可能并不性感,但绝对是非常必要的。它成为了微软的很多产品的基础,是构建了无数业务领域的原型。同时微软也期望它能成为快速实现数据交换和迁移的标准,这个有点像菜鸟网络推出的奇门,让所有TMS、OMS、WMS都基于一套数据接口API进行互通,一套标准是为了解决一个行业问题,而不是具体某一个企业一个集团的问题。 我们发现CDM的理念跟我们想要的“企业级的数据标准”是非常吻合的。但是我们也不能照搬照抄,虽然微软的CDM很好的解决了数据割裂问题,但就模型来说就够大家喝一壶了,模型库非常庞大而且复杂,学习成本巨高。 数字化时代软件会产生新的技术流派 我们知道传统软件的设计理念:侧重在模型对业务支撑全面性上。优点体现为配置丰富,缺点模型设计过于复杂,刚开始有前瞻性,但在理解、维护都非常困难,随着业务发展系统原先的设计逐渐腐化,异常笨重。 而Oinone的CDM设计理念:侧重在简单、灵活、统一上,体现为在上层应用开发时,每一业务领域保持独立,模型简单易懂,并结合Oinone的低代码开发机制进行快速开发,灵活应对业务变化。 所以我更想说Oinone的CDM是微软CDM的在原有基础上,与互联网架构结合,利用Oinone低代码开发平台特性形成新的工程化建议。Oinone-CDM不以把模型抽象到极致,支撑“所有业务可能性”为目标,而是抽象80%通用的设计,保持模型简单可复用,来解决数据割裂问题,并保持业务线独立自主性,快速创新的能力。 图5-1-1 Oinone-CDM要解决的问题 二、Oinone的CDM本质是创新的工程化建议 引入CDM以后系统工程结构会有什么变化,跟大家认知的互联网架构有什么区别。 原本上层的业务线系统,需要调用各个业务平台提供的功能,增加CDM以后也就是我们右的图,每个业务线就像一个独立右边。看上去复杂了,其实对业务线来说更加简单了。 互联网整体平台化带来的问题: 业务线每次业务调整都需要给各个平台提需求 业务平台研发需要了解所有业务线的知识再做设计,对研发要求非常高 各个业务域的不同需求相互影响包括系统稳定性、研发对需求响应的及时性 结合oinone特性提出的新工程建议: 一些通用性模块继续以平台化的方式存在,能力完全复用。 业务线自建业务平台,保持业务线的独立性和敏捷性 业务线以CDM为原型,保证核心数据不割裂,形成一致的数据规范 图5-1-2 引入CDM概念后的工程结构对比 三、CDM思路示意图 该示例中OinoneCDM的商品域不仅仅提供标准实体,保证各个业务系统的对商品的通用需求、简单易懂,在我们星空系列业务产品中如全渠道运营、B2B交易等系统以此为基础建立属于自身个性化的实体,可以扩展标准实体也可以增加和标准实体相关的新实体。 带来的好处: 通过多种继承方式,继承后的模型可扩展模型本身、模型行为等,从而解决业务独立性问题。 通过CDM层统一数据模型,从而解决多应用数据割裂问题 图5-1-3 Oinone-CDM思路示意图

    2024年5月23日
    1.3K00
  • 3.0.5版本更新说明-20220815

    版本号:3.0.5发布日期:2022.08.15更新要点: 前端更新:包括界面设计器布局优化和加密方式修改,数据编码组件优化,字段数据字典查看,表达式展示优化,Dialog组件改进。 后端更新:涵盖界面设计器布局支持和页面设计器迭代,数据编码元数据引用,数据字典查询功能,以及tableWidget改进。 1 发布概要 前端 界面设计器左树右表、级联设计 实现页面左树右表、级联布局 修改加密 模型设计器迭代优化 数据编码组件优化,支持选择已有编码 字段的数据字典可直接点击查看 表达式内支持展示已废弃的字段,不可选中 后端 界面设计器左树右表 layout支持 页面设计器迭代6,除树表级联部分 数据编码元数据引用 数据编码、数据字典所属模块查询 tableWidget的rowActions区域变更为rowActionWidget 2.版本信息 <pamirs.middleware.version>3.0.1</pamirs.middleware.version> <pamirs.boot.version>3.0.3</pamirs.boot.version> <pamirs.core.version>3.0.4.2</pamirs.core.version> <pamirs.tenant.version>3.0.1</pamirs.tenant.version> <pamirs.lowcode.version>3.0.1</pamirs.lowcode.version> <pamirs.designer.version>3.0.2-SNAPSHOT</pamirs.designer.version> <pamirs.workflow.designer.version>3.0.6</pamirs.workflow.designer.version> <pamirs.model.designer.version>3.0.3</pamirs.model.designer.version> <pamirs.logic.designer.version>3.0.1</pamirs.logic.designer.version> <pamirs.ui.designer.version>3.1.6-cpc</pamirs.ui.designer.version> <pamirs.data.designer.version>3.0.3</pamirs.data.designer.version> <pamirs.data.visualization.version>3.0.3</pamirs.data.visualization.version> <pamirs.distribution.version>3.0.1</pamirs.distribution.version> <pamirs.welcome.version>3.0.3</pamirs.welcome.version> <pamirs.gemini.version>3.0.6</pamirs.gemini.version> <pamirs.paas.version>3.0.3</pamirs.paas.version> 如果您有任何问题、建议或反馈,请随时联系我们。为了获得最佳体验,建议请升级至最新版本。我们将继续努力改进产品,提供更好的服务。谢谢支持!

    2022年8月15日
    1.2K00

Leave a Reply

Please Login to Comment