最简单的最快数据查询模式是：
- 单个表或视图
- 在服务器上进行预筛选，以获得您所需的内容
- 为预期查询正确索引列
设计应用时，需要考虑如何快速查询数据。 查询数据的最佳方式是使用包含所需全部信息的单个表或视图，并在应用中显示数据之前在服务器上对其进行筛选。 还需要确保用于筛选或排序数据的列已被正确索引。 这使得你的应用更快、更流畅。
例如，假设你有一个画廊，其中显示了客户及其销售人员的列表。 如果将客户和销售人员信息存储在单独的表中，则需要使用查找来获取每个客户的销售人员名称。 这会降低应用速度，因为它需要对其他表运行许多查询。 更好的方法是创建一个视图，该视图将客户和销售人员信息合并在一个表中，并将该视图用作库的数据源。 然后，应用只需运行一个查询即可获取它所需的所有数据。
查询速度和数据规范化之间存在权衡。 数据规范化意味着仅存储一次数据，并避免重复。 这有助于保持数据一致且准确。 但是，有时需要复制某些数据，使查询更快、更轻松。 需要在应用设计和表结构中平衡这两个目标。 否则，你的应用会很慢且滞后，因为它需要执行大量工作来筛选和联接来自不同表的数据。
使用服务器端视图
视图可能是帮助平衡这些目标的最常见工具。 它们为查询提供单个表结构，预筛选查询中所需的数据，并启用与其他表的查找和联接。 由于筛选器、视图的查找和联接是在服务器上计算的，因此有效负载和客户端计算都最小化。
避免对图库进行过多查找
画廊可以显示数据源中的许多记录。 但有时，你需要显示另一个数据源中与原始数据源相关的其他信息。 例如，你有一个显示客户列表的画廊，并且你想要显示分配给每个客户的销售人员的名称。 销售人员的名称存储在与客户信息不同的数据源中。 若要显示销售人员的姓名，需要使用查找函数来查找其他数据源中的匹配记录。 这将使用查找值展开原始表。
但是，如果有大量记录和大量查找，表的展开速度可能会非常慢。 对于库中的每个记录，应用需要对其他数据源运行单独的查询并获取查找值。 这意味着应用可能需要为每个记录运行许多查询，这可能需要很长时间并影响应用性能。 这种反模式有时称为“N 平方，（n^2）”或“N+1”问题。
使用“StartsWith”或“Filter”
Power Fx 提供了多种搜索数据的方法。 通常，应该使用利用索引的表达式，例如 StartsWith 或 Filter，而不是像 In 这样读取整个表的表达式。 In 运算符适用于内存中集合或者外部数据源表非常小的情况。
考虑复制数据
有时，数据在查询中访问速度缓慢，因为它以不同的位置或格式存储。 若要加快查询速度，可以复制慢速数据并将其存储在快速且易于查询的表中。 但是，这意味着本地数据可能不是原始数据的更新版本。 然后运行另一个进程来定期更新本地数据。 此过程可以是 Power Automate 流、插件、存储过程或任何其他方法，可以将数据从一个位置移到另一个位置。
更新本地数据的频率要求取决于业务需求。 你的应用需要多新鲜数据？ 例如，假设你为 Contoso 工作，该公司销售自行车。 可用自行车列表存储在产品数据库中，可以通过自定义连接器中的 API 进行访问。 但是，假设 API 调用速度缓慢，因此你决定复制产品数据并将其存储在表中。 然后，创建一个视图，该视图将表与应用的其他相关数据组合在一起。 您还创建了一个 Power Automate 流，该流每天运行并通过 API 将最新产品数据更新至表格。 然后，应用可以更快速地查询本地数据，而这些数据至多只有一天的历史。
复制数据是企业级应用程序中的一种常见技术，以确保良好的性能。 可以使用 Dataverse 插件、存储过程或数据移动将数据复制到针对查询优化的单个表中。 关键问题是：此数据必须是最新的吗？ 如果能够承受一些延迟，则可以使用此技术加快应用速度。
建议
若要实现此目标，请考虑以下问题和建议：
- 对于客户来说，查看库或数据网格中的数据价值有多重要？ 先选择记录，然后以窗体显示数据是可以接受的吗？
- 视图是否可以执行必要的准备工作才能以正确的格式查看数据？
- 是否将使用“StartsWith”起作用的“IN”运算符？
- 您的数据需要有多新？ 是否有数据重复策略可用于让查询在默认情况下处理单个表？