1. Oinone社区Home

深度分页问题优化方案

• • Uncategorized • 1485 views

问题原因

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
0 0
Previous 2023年6月20日 pm4:07
Next 2023年11月2日 pm1:58

相关推荐

  • Excel导出模块翻译值 未分类

    Excel导出模块翻译值

    由于目前翻译资源导出只可以导出应用资源，无法导出模块资源，所以暂时提供以下方法导出模块资源。6.2.11、5.7.4.20 之前版本验证 方案一： 导出环境覆盖以下类 package pro.shushi.pamirs.translate.template.imports; import com.alibaba.fastjson.JSON; import com.google.common.collect.Lists; import org.apache.commons.collections4.CollectionUtils; import org.apache.commons.lang3.StringUtils; import org.springframework.stereotype.Component; import pro.shushi.pamirs.file.api.context.ExcelDefinitionContext; import pro.shushi.pamirs.file.api.entity.ExcelExportFetchDataContext; import pro.shushi.pamirs.file.api.extpoint.impl.DefaultExcelExportFetchDataExtPoint; import pro.shushi.pamirs.file.api.model.ExcelExportTask; import pro.shushi.pamirs.framework.connectors.data.sql.Pops; import pro.shushi.pamirs.framework.connectors.data.sql.query.LambdaQueryWrapper; import pro.shushi.pamirs.framework.connectors.data.sql.query.QueryWrapper; import pro.shushi.pamirs.meta.annotation.Ext; import pro.shushi.pamirs.meta.annotation.ExtPoint; import pro.shushi.pamirs.meta.annotation.fun.extern.Slf4j; import pro.shushi.pamirs.meta.api.Models; import pro.shushi.pamirs.meta.api.dto.wrapper.IWrapper; import pro.shushi.pamirs.meta.common.lambda.LambdaUtil; import pro.shushi.pamirs.meta.common.util.PStringUtils; import pro.shushi.pamirs.meta.constant.SqlConstants; import pro.shushi.pamirs.meta.domain.module.ModuleDefinition; import pro.shushi.pamirs.resource.api.enmu.TranslationApplicationScopeEnum; import pro.shushi.pamirs.resource.api.model.ResourceTranslation; import pro.shushi.pamirs.resource.api.model.ResourceTranslationItem; import pro.shushi.pamirs.translate.constant.TranslateConstants; import pro.shushi.pamirs.translate.proxy.TranslationItemExportProxy; import pro.shushi.pamirs.translate.service.TranslationDslNodeVisitor; import pro.shushi.pamirs.translate.template.TranslateTemplate; import pro.shushi.pamirs.translate.utils.UniversalParser; import java.util.*; import java.util.stream.Collectors; import static pro.shushi.pamirs.translate.constant.TranslateConstants.FIELD_TO_EXCLUDE; /** * @author Adamancy Zhang * @date 2020-11-04 18:09 */ @Slf4j @Component @Ext(ExcelExportTask.class) @SuppressWarnings({"unchecked"}) public class ResourceTranslationExportExtPoint extends DefaultExcelExportFetchDataExtPoint { private String resLangCodeColumn = PStringUtils.fieldName2Column(LambdaUtil.fetchFieldName(ResourceTranslationItem::getResLangCode)); private String langCodeColumn = PStringUtils.fieldName2Column(LambdaUtil.fetchFieldName(ResourceTranslationItem::getLangCode)); private String moduleColumn = PStringUtils.fieldName2Column(LambdaUtil.fetchFieldName(ResourceTranslationItem::getModule)); @Override @ExtPoint.Implement(expression = "context.name=="" + TranslateTemplate.TEMPLATE_NAME + "" && context.model=="" + ResourceTranslation.MODEL_MODEL + """) public List<Object> fetchExportData(ExcelExportTask exportTask, ExcelDefinitionContext context) { ArrayList<Object> objects = new ArrayList<>(); Map<String, Object> queryData = exportTask.getConditionWrapper().getQueryData(); TranslationItemExportProxy data = JSON.parseObject(JSON.toJSONString(queryData), TranslationItemExportProxy.class); LambdaQueryWrapper<TranslationItemExportProxy> queryWrapper = Pops.<TranslationItemExportProxy>lambdaQuery() .from(TranslationItemExportProxy.MODEL_MODEL) .eq(StringUtils.isNotBlank(data.getModule()), ResourceTranslationItem::getModule, data.getModule()) .eq(ResourceTranslationItem::getResLangCode, TranslateConstants.RES_LANG_CODE) .eq(StringUtils.isNotBlank(data.getLangCode()), ResourceTranslationItem::getLangCode, data.getLangCode()) .eq(data.getState() != null, ResourceTranslationItem::getState, data.getState()) .like(StringUtils.isNotBlank(data.getResLangInclude()), ResourceTranslationItem::getOrigin, data.getResLangInclude()) .like(StringUtils.isNotBlank(data.getTargetInclude()), ResourceTranslationItem::getTarget, data.getResLangInclude()); Map<String, String> moduleNameMap = Models.origin().queryListByWrapper(Pops.<ModuleDefinition>lambdaQuery() .from(ModuleDefinition.MODEL_MODEL) .eq(StringUtils.isNotBlank(data.getModule()), ModuleDefinition::getModule, data.getModule())) .stream() .collect(Collectors.toMap(ModuleDefinition::getModule, ModuleDefinition::getDisplayName, (_a, _b)…

    yexiu's avatar yexiu
    2025年8月21日
    56800

  • 梅丛银

    认识陈鹏程及数式核心团队同学已经有一段时间了，在我们多次的交流讨论中时常会谈及：未来中国哪家软件企业能在互联网云原生时代走出来超越传统软件企业？史昂说这是他的梦想，也是他们团队这么多年坚持技术和产品研发与应用优先思考之路。史昂及数式核心团队面向企业应用市场历经三年的潜心研发和实战交付，推出Oinone产品及配套的低代码平台工具：对比国内外应用软件平台在开放生态和云原生均有它的继承性和独特性，特别是将技术平台赋予企业各种业务领域属性，便于企业客户和开发伙伴的二次开发并能快速搭建各类企业核心应用场景是Oinone的最大亮点。Oinone的内在特点之一是参考了全球最大开源ERP Odoo的元数据模型设计，同时基于业务中台架构和云原生技术，形成了自己一套国际化的快速开发平台、建模规范和应用产品，通过自己进场落地很多品牌企业的应用中台化不断迭代升级，走出了一条具有显著特色的新应用软件之路。史昂及团队特点谦卑、善于思考，善于吸收他山之精华，这是创业团队难能可贵之点，由此能善于与生态伙伴合作也是能够走的更远更长的基础基因。最后希望和祝愿Oinone能为中国企业在云时代数字化实践做出更多的贡献，为软件产业构建强大的应用生态和开发社区，真正树立起Oinone自己的软件品牌形象。 资深IT咨询专家&浩鲸云智能专家学院院长：梅丛银

    史, 昂's avatar 史, 昂
    Oinone 7天入门到精通 2024年5月23日
    1.5K00
  • 4.2.x版本更新说明-20230607 4.x

    4.2.x版本更新说明-20230607

    版本号：4.2.x发布日期：2023.06.07更新要点：前端1.优化工作台搜索样式，提升用户体验2.修复表单自动填充和必填校验异常，确保数据准确性3.提升请求头参数传递效率，加快数据传输速度后端：1.修复工作流动态用户获取失败，保障流程顺畅进行2.优化List逗号存储触发器，提升数据处理效率3.解决多对多关联字段查询问题，确保数据查询准确性4.修复Out转换Map数据转换问题，提升数据转换准确 1 发布概要 1.1 前端 发布内容： 优化工作台搜索区悬停样式的问题 修复表单自动填充的问题 修复必填校验提示异常出现的问题 请求头添加module参数，传递url上的module参数 1.2 后端 发布内容: 修复工作流动态用户获取用户数据失败问题 修复List逗号存储，触发器触发失败问题 修复多对多关联字段不是CODE情况下，查询不到值的情况 修复Out转换Map数据转换问题 2.最新版本包信息 !–平台基础jar包–> <pamirs.middleware.version>4.7.0</pamirs.middleware.version> <pamirs.k2.version>4.7.3.2</pamirs.k2.version> <pamirs.boot.version>4.7.7.5</pamirs.boot.version> <pamirs.framework.version>4.7.5.3</pamirs.framework.version> <pamirs.core.version>4.7.7.4</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.8</pamirs.workflow.version> <pamirs.flow.designer.base.version>4.7.3.1</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.1</pamirs.model.designer.version> <pamirs.ui.designer.version>4.7.4.1</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.1</pamirs.eip.designer.version> 如果您有任何问题、建议或反馈，请随时联系我们。为了获得最佳体验，建议请升级至最新版本。我们将继续努力改进产品，提供更好的服务。谢谢您的支持！

    shao's avatar shao
    2023年6月20日
    1.6K00
  • 组件数据交互基础（v4） 前端

    组件数据交互基础（v4）

    阅读之前 你应该： 了解DSL相关内容。母版-布局-DSL 渲染基础（v4） 了解SPI机制相关内容。组件SPI机制（v4） 了解组件相关内容。 Class Component(ts)（v4） 组件生命周期（v4） 组件数据交互概述 数据结构设计 数据结构分为三大类，列表（List）、对象（Object）以及弹出层（Popup）。 列表（List）：用于多条数据的展示，主要包括搜索（用户端）、自定义条件（产品端）、排序、分页、数据选中、数据提交、数据校验功能。 对象（Object）：用于单条数据的展示，主要包括数据提交、数据校验功能。 弹出层（Popup）：用于在一块独立的空间展示对应类型的数据。 数据结构与对于的内置视图类型： 列表（List）：表格视图（TABLE）、画廊视图（GALLERY） 对象（Object）：表单视图（FORM）、详情视图（DETAIL） 数据交互设计原则 组件与组件之间的结构关系是独立的，组件与组件之间的数据是关联的。因此，数据交互整体采用“作用域隔离（View），行为互通（CallChaining），数据互通（ActiveRecords）”这样的基本原则进行设计。实现时，围绕不同视图类型定义了一类数据结构所需的基本属性。 在弹出层进行设计时，使用Submetadata的方式，将包括弹出层在内的所有组件包含在内，以形成新的作用域。 通用属性及方法 属性 rootData：根数据源 dataSource：当前数据源 activeRecords：当前激活数据源 为了在实现时包含所有数据结构，我们统一采用ActiveRecord[]类型为所有数据源的类型，这些数据源在不同类型的视图中表示不同的含义： 列表（List）：dataSource为列表当前数据源，activeRecords为列表中被选中的数据。特别的，showDataSource为当前展示的数据源，它是dataSource经过搜索、排序、分页等处理后的数据源，也是我们在组件中真正使用的数据源。 对象（Object）：daraSource和activeRecords总是完全一致的，且长度永远为1。因此我们有时也在组件中定义formData属性，并提供默认实现：this.activeRecords?.[0] || {}。 方法 reloadDataSource：重载当前数据源 reloadActiveRecords：重载当前激活数据源 由于底层实现并不能正确判断当前使用的数据类型，因此我们无法采用统一标准的数据源修改方法，这时候需要开发者们自行判断。 重载列表数据源 cosnt dataSource: ActiveRecord[] = 新的数据源 // 重载数据源 this.reloadDataSource(dataSource); // 重置选中行 this.reloadActiveRecords([]); 重载表单数据源 cosnt dataSource: ActiveRecord[] = 新的数据源（数组中有且仅有一项） // 重载数据源 this.reloadDataSource(dataSource); // 此处必须保持相同引用 this.reloadActiveRecords(dataSource); 内置CallChaining（链式调用） 在自动化渲染过程中，我们通常无法明确知道当前组件与子组件交互的具体情况，甚至我们在定义当前组件时，并不需要关心（某些情况下可能无法关心）子组件的具体情况。这也决定了我们无法在任何一个组件中完整定义所需的一切功能。 为了保证组件行为的一致性，我们需要某些行为在各个组件的实现需要做到组件自治。以表格视图为例：当view标签在挂载时，我们无法确定应该怎样正确的加载数据，因此，我们需要交给一个具体的element标签来完成这一功能。当element标签对应的组件发生变化时，只需按照既定的重载方式将数据源提交给view标签即可。 除了保证组件行为的一致性外，我们不能完全的信任第三方框架对组件生命周期的处理顺序。因此，我们还需要对组件行为进行进一步的有序处理。以表格视图为例：我们希望搜索视图（SEARCH）的处理总是在加载数据前就处理完成的，这样将可以保证我们加载数据可以正确处理搜索条件，而这一特性并不随着模板结构的变化而发生变化。 平台内置的CallChaining mountedCallChaining：挂载时钩子； refreshCallChaining：刷新时钩子； submitCallChaining：提交时钩子； validatorCallChaining：验证时钩子； 优先级常量 VIEW_WIDGET_PRIORITY（0）：视图组件优先级 FETCH_DATA_WIDGET_PRIORITY（100）：数据提供者组件优先级 SUBVIEW_WIDGET_PRIORITY（200）：子视图组件优先级 未设置优先级的hook将最后执行，在通常情况下，你无需关心优先级的问题。 注意事项 CallChaining通常不需要手动初始化，仅需通过inject方式获取即可。 CallChaining的hook/unhook方法需要在组件生命周期的mounted/unmounted分别执行，如无特殊情况，一般通过this.path作为挂载钩子的唯一键。 在字段组件中使用mountedCallChaing @Widget.Reactive() @Widget.Inject() protected mountedCallChaining: CallChaining | undefined; protected mountedProcess() { // 挂载时处理 } protected mounted() { super.mounted(); this.mountedCallChaining?.hook(this.path, () => { this.mountedProcess(); }); } protected unmounted() { super.unmounted(); this.mountedCallChaining?.unhook(this.path); } 字段组件的mountedCallChaing并不是必须的，因此我们未进行内置处理。 一般的，当视图数据被加载完成时，字段组件的formData和value等属性，将通过响应式自动获取对应的值，因此在大多数情况下是不需要使用这一特性的。 当我们需要对字段获取的值做进一步初始化处理时，我们将需要使用这一特性。例如TreeSelect组件，必须在初始化时填充树下拉所需的结构化数据，这样才能正确展示对应的值。 当字段组件的mounted方法被执行时，我们还未执行视图数据加载，因此，在我们无法在mounted方法中操作formData和value等属性，只有在mountedCallChaining被view标签执行时，按照执行顺序，此时字段的mountedChaining将在视图数据被加载完成后执行。 数据源持有者和数据源提供者 在设计上，我们通常将view标签设计为数据源持有者，将element标签设计为数据源提供者。 原则上，在一个视图中有且仅有一个数据源提供者。 即：当一个element标签的实现组件通过reloadDataSource方法向view标签设置数据源，我们就称该实现组件为当前view标签的数据源提供者，view标签为数据源持有者。 provider/inject 阅读该章节需要理解vue的依赖注入原理 在实现上，我们通过provider/inject机制将上述通用属性/方法进行交替处理，就可以实现根据模板定义的结构进行隔离和共享功能。 例如dataSource属性的实现： /** * 上级数据源 * @protected */ @Widget.Reactive() @Widget.Inject('dataSource') protected parentDataSource: ActiveRecord[] | undefined; /** * 当前数据源 * @protected */ @Widget.Reactive() private currentDataSource: ActiveRecord[] | null | undefined; /** * 提供给下级的数据源 * @protected */ @Widget.Reactive() @Widget.Provide() public get dataSource(): ActiveRecord[] | undefined { return this.currentDataSource || this.parentDataSource; } 不足的是，由于provider/inject机制特性决定，通过provider提供的属性和方法，在某些情况下可能会进行穿透，导致组件通过inject获取的属性和方法并非是我们所期望的那样，因此，我们仍然需要进行一些特殊的处理，才能正确的处理子视图的数据交互，这一点在对象（Object）类型的视图中会详细介绍。 运行时上下文（metadataHandle/rootHandle） 在之前的文章中，我们知道前端的字段/动作组件渲染和后端元数据之间是密不可分的。 在数据交互方面，后端元数据对于字段类型的定义，将决定从API接口中获取的字段、数据类型和格式，以及通过API接口提交数据到后端时的字段、数据类型和格式。 数据类型和格式可以通过field标签的data属性，获取到经过后端编译的相关字段元数据。 那么，我们该如何决定，当数据提供者向后端发起请求时，应该获取哪些字段呢？ 因此，我们设计了RuntimeContext机制，并通过metadataHandle/rootHandle机制，在任何一个组件都可以通过view标签正确获取已经实现隔离的运行时上下文机制。 以表单视图为例，我们来看这样一个经过合并后的完整视图模板： （以下模板所展示的并非实际的运行时的结果，而是为了方便描述所提供的完整视图模板） <view type="FORM"> <element widget="actions"> <action…

    oinone's avatar oinone
    2023年11月1日
    1.9K00

  • 模型设计器

    史, 昂's avatar 史, 昂
    Oinone 7天入门到精通 2024年1月20日
    2.4K00

Leave a Reply

Please Login to Comment