如何优化列表的性能？

导语

列表是用来展示基础资料和单据数据用的，一般只支持单个实体对象，大多数的情况下基础资料和单据上的数据都不会太庞大，但是有些业务场景比如物料，凭证，采购入库单等由于在业务上是用来记录流水数据用的，再加上这些单据在设计时关联了太多的基础资料，这样就会导致除了查询主表数据外还需要关联相当多的基础资料数据，极端情况下如果基础资料还存在跨库的情况，那么情况会更加的糟糕，因为基础资料都是需要单独进行查询的。

还有就是列表的快速搜索在设计上为了提高用户的体验，都采用了全字匹配的方式进行，这样对数据的索引是不太友好的，数据量小的情况不会导致太大的问题，即使全表扫描代价不会太大，因为大部分的单据数据量都不会太大，但是对于以上情况，如果去全表扫描数据那么代价是很大的，会对数据库导致相当大的压力。

在设计列表时一般是需要设计师体验用户的真实需求，以“人”为中心的设计理念，需要设计师们充分去收集每个用户需要看到或者处理哪些数据，不要把太多无关的数据展现在用户的面前，让用户体验到设计者的用心，所以一般推荐在列表一打开时看到的数据就是用户想要的，所以列表的默认条件的设置至关重要，这个也同样影响到列表的性能，一般来说，一个用户能看或者处理的数据是极其有限的，那么需要设计师们去“提炼”出那部分最重要的数据出去，这种数据肯定是少量的，如果初始过滤条件设计的不合理，那么对用户来说不但形成了干扰，而且非常不便，需要再设定一下条件才能查到自己想要的数据，同时对服务器来说也造成了相当大的压力。

综合以上情况，所以优化要从多个方面去入手，这个不光是技术问题，也是设计问题，也是系统规划的问题。

典型场景举例

1.    快速搜索字段包含有多个字段，快速搜索默认采用全字匹配的方式进行搜索，翻译成Sql就是like %xxx%，这样会用不到索引，如果主表数据量比较大，或者快速搜索字段带了基础资料的情况下，基础资料也比较大的时候，将会有很多大表进行全表随机扫描，列表默认取10W条数据，数据取到之后再根据排序条件返回前10W条数据。

对于这种情况，本质是用户想要在海量数据里面进行大数据的模糊搜索，由于关系数据的对这种场景的支持有限，只能采用妥协的策略来进行优化，优化方法如下：

1.1   将多个字段的模糊搜索改为单个，这样减少数据的搜索范围

1.2   将模糊搜索改为左匹配搜索，这样改进之后sql是可以用到索引的，但是这样用户只能搜索到左边部分匹配的内容，如果匹配内容不在内容开头是搜索不到的

2.    有些业务想要在列表处理大数据业务，这种情况本身是不太合理的，列表是用来查询少量数据用的，大数据的处理应该单独去设计，原因如下：

2.1   业务操作人员能处理的数据有限，而且大部分的业务都是有规则的，人员处理都是属于重复劳动，效率低不说，而且容易出错，能设计成自动化的业务尽量用自动化去实现

2.2   列表默认显示最多10W条数据，其实对于人来说这些数据量处理起来都是过大的，以我看来1000以内的都是可以接受的，所以一般不需要看这么大数据量，如果想业务人员更高效的定位到数据，业务设计师应该从具体业务的场景来布局合理的搜索定位条件，或者更加AI智能的方式去实现。

2.3   由于以上原因，所以列表的“选择全部”一般是不需要的，其实需要“选择全部”场景是不需要选数据的，如果用了“选择全部”反而是选不到所有数据的，“选择全部”只提供最大条数内的数据选择。

2.4   基于第2点的描述，列表提供单页显示1W条的数据是不合理的，但是这块目前没有办法优化，只能指定用户不要使用每页1W条，因为1W条数据不但处理不了，而且1W数据加载出来也是相当大的，不光是对数据库造成压力，而且数据传输到前端也需要消耗相当大的带宽。

解决方案

1.去掉快速搜索的“全选”

2. 在单据参数将模糊查询方式改为从...开始

3. 列表默认查询10W条数据，如果数据量比较大，可以在单据参数将“列表查询最大限制数”调小一些

4. 去掉列表的默认排序

5. 其他优化方式

• 调优SQL，加索引

• 限制输入的过滤条件，缩小查询范围

方案解析与价值

方案1的原理是用配置的全部字段去搜索数据的方式解析成sql就是多个字段的OR关系查询，多个字段OR查询时如果匹配