针对系统初始化查询及条件查询缓慢的问题，通过将数据表拆分为实时表与历史表，减少实时表数据量，并在查询页面增加是否查询实时数据的选项，降低了查询负担。同时，优化初始化查询默认不执行，仅在用户明确需求时才进行查询，以及对模糊查询进行控制，提升查询效率。这些改进显著改善了后台管理员使用查询流水功能的体验，但仍有持续优化空间，如实时表数据量的控制。
业务现状:
功能：xx流水查询
问题：系统初始化查询缓慢以及条件查询缓慢
数据库：oracle 服务器配置：32核 64G内存
表情况：设置7张表平均单张数据量超过2亿
要求：不能改变现有业务逻辑，即功能改查询功能不能对数据产生的业务进行修改
步骤:
一，对表进行分表
经过询问业务使用人员，发现使用查询功能最重要的是查询近期的数据，而不是历史数据，通过数据分析表日增长在300W上线浮动，每逢周六日以及国家法定节假日数据库增长基本为0
处理方法：
数据库处理：将现有的表拆分为实时表与历史表，实时表为当前表只存储当前7天（可动态配置）的数据，历史表则存储旧的历史数据（由于历史表查询的相对较少，不做优化，如在需要优化可按照年，半年，月区分开来）
查询页面处理：新增一个下拉框，后台管理可以选择查询实时数据与当前数据
这样优化之后，减少了当前表的数据量，从物理层面较少了数据量，查询数据有一定的提升
二，初始化默认不查询
当使用后台管理进行到我们xx流水查询模块，我们会有一个初始查询，默认查询50条数据同时查询出总的条数以及分页数据
业务人员业务使用：其实后台管理很多时候并不需要查询流水，更多的是查询根据特定条件例如：录入流水ID,用户姓名，手机号码，时间范围等查询查询
处理方法：在界面上做一个下拉框，需要用户选择是否 查询数据 手动选择 “是” 后进行流水功能查询
这样优化后，后台管理初始化进来不需要查询流水，系统管理员可以在输入过滤条件：录入流水ID,用户姓名，手机号码，时间范围等查询查询，这样效率就大大地提升了
三：模糊查询优化
使用条件查询的例如手机号码查询，系统设计默认是支持模糊查询的，这样即便用户输入了完整的手机号码，进入后台还是执行模糊查询语句，这样相对较为耗时
处理方法：中台条件新增是否模糊查询，初始化默认不模糊查询，只有用户选择模糊查询再进行模糊查询
这样我们输入了完整的手机号码进行查询，数据又对手机号码字段新增了索引，这样查询效率就大大地提升
总结：按照上诉思路实现后，后台管理员使用查询xx流水功能就非常快，在上线一段时间后使用人员对实际体验较为满意
不足之处还是存在，我们实时表日产生的数据量在300W,忽略掉休息日，表总数据量还是保持在1500W左右，要做到完美优化，还是得持续版本迭代
扫一扫
985
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
