综上所述，列表的性能优化不仅是技术层面的问题，更是业务设计时就需要考虑的关键设计点。

因此，本文从产品设计角度，为大家介绍列表性能优化的方法。

为提高用户的体验，在设计列表的快速搜索功能时，采用了全字匹配的方式。在单据数据量较大时，全表扫描的代价非常高，给数据库造成了很大的压力。且快速搜索字段允许包含有多个字段，默认采用全字匹配的方式进行搜索，翻译成SQL就是“like %xxx%”，这样会导致索引不可用。

如果主表数据量较大，或者快速搜索字段带了基础资料且基础资料也较大时，将会进行大量大表的全表随机扫描，取到全部数据之后再根据排序条件返回列表默认需要的前10W条数据。

在列表中，不适合做海量数据的批量处理，原因如下：

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

2）列表默认显示最多10W条数据，对人为处理来说，数据量过大，无法判断数据的合规性。若列表分页的数据设置过大，如按1W条数据分页，不光是对数据库造成压力，而且数据传输到前端也需要消耗相当大的带宽。

3）列表排序的模式有SqlQuery和IdQuery两种。采用IdQuery模式，会将列表查询上限数量的ID存入临时表或缓存。该取数SQL会带上列表默认的排序、汇总字段，如排序字段无索引且数据量较大时，即使数据有做分页，对首次加载性能也有较大影响。

在场景一中，用户的本质需求是在海量数据中进行大数据的模糊搜索。对于查询来说，NoSql数据库优于关系数据库，百万级、千万级甚至亿级的查询对非关系数据库（比如ES）来说毫无压力。

由于关系数据库对该场景的支持有限，且目前全文索引的方案尚未成熟，采用妥协的策略来进行优化，优化方法如下：

1）将多个字段的模糊搜索改为单个，减少数据的搜索范围。

多个字段OR查询时，数据库在基于成本或者规则的前提下会认为使用全表扫描比直接走索引的代价更小，所以会优先使用全表扫描的方式去扫描数据，而单个字段查询则不存在该问题。

配置方式为：关闭快速搜索中的“多字段搜索”