Azure Synapse Analytics 无服务器 SQL 池的性能优化指南

适用于：Azure Synapse Analytics

本文可帮助你提高 Azure Synapse Analytics 无服务器 SQL 池的性能。

有关如何实现最佳性能和防止与 Azure Synapse Analytics 无服务器 SQL 池上的资源约束相关的故障的信息，请参阅后面的几个部分。

最佳做法和故障排除指南

以下文章中的信息和策略可以帮助你从无服务器 SQL 池中获得最佳性能。 建议使用这些文章查看用例并排查常见问题。

• Azure Synapse Analytics 中无服务器 SQL 池的最佳做法
• 排查 Azure Synapse Analytics 中的无服务器 SQL 池问题

了解无服务器 SQL 池上的缩放

无服务器 SQL 池不需要手动选择正确的大小。 系统根据查询要求自动调整大小，从而管理基础结构并为解决方案选择合适的大小。

Delta Lake 文件的性能优化指南

有关 Delta Lake 文件的性能优化的详细信息，请参阅以下资源：

• Delta Lake 文档页。
• 什么是 Delta Lake
• 在 Azure Synapse Analytics 中使用无服务器 SQL 池查询 Delta Lake 文件

CSV 文件的性能优化指南

查询无服务器 SQL 池上的 CSV 文件时，确保高性能的最重要任务是在外部表上创建统计信息。 虽然统计信息是在 Parquet 和 CSV 文件上自动创建的，并且通过使用 OPENQUERY()访问，但使用外部表读取 CSV 文件需要手动创建统计信息。

有关统计信息在查询无服务器 SQL 池中的 CSV 文件时所扮演的角色的更多详细信息，请参阅以下文章：

• 查询 CSV 文件
• 无服务器 SQL 池中的统计信息
• 手动为 CSV 文件创建统计信息
• 查询超时过期

有关使用 Power BI 和其他报告工具的建议

使用 Power BI 和其他报告工具时，建议采用以下最佳做法：

• 始终检查租户位置。
• 设置缓存以提供更好的用户体验。
• 避免将数百万条记录返回到仪表板。
• 使用计划的刷新来避免并行查询执行，从而耗尽 SQL 无服务器池资源。
• 使用 Spark 预先聚合常见分析查询。 这种“写入一次/多次读取”方法可避免连续运行的繁重查询。
• 对于不同数据存储之间的联接：使用筛选器避免跨 Azure 基础结构移动的大数据卷。
• 对字符数据类型使用 Latin1_General_100_BIN2_UTF8 排序规则。 当工具从存储读取数据时，此排序规则会向下推送筛选器，从而避免将所有数据从存储传输到无服务器 SQL 池。
• 如果在运行查询时将数据强制转换为 或 charvarchar ，请使用最佳大小。 如果可能，请避免使用 VARCHAR(MAX)。
• 自动推理会将数据类型转换为可能不是最佳格式。 WITH使用 子句优化数据类型。
• SQL 无服务器池资源Azure Synapse有限制。 同时运行查询将消耗资源。 当多个刷新并行发生时，通常会看到 Power BI (PBI) 仪表板达到资源限制。 计划的刷新和负载测试有助于避免此问题。 此外，使用多个Azure Synapse工作区可以满足更高的并发要求。
• 创建视图后，可以运行查询sys.columns或使用 sp_describe_first_result_set 和 select top 0 from <view> 检查数据类型。 此方法比使用 SELECT * FROM...更快且成本更低。
• 使用 语句生成器 自动为查询创建最佳列格式。
• OPENJSON使用 函数将嵌套的 JSON 数据公开为列。 但是，如果还使用 AS JSON 命令，则列类型必须为 NVARCHAR(MAX)。 此方法对于性能并不理想。 最佳选择是使用 WITH 子句将嵌套数组公开为列。
• 分析存储中不使用 Cosmos DB 事务存储分区键。 在 Azure Synapse Link 中，现在可以为事务数据建模，以优化数据引入和点读取。

额外的指导和最佳做法

第三方信息免责声明

本文中提到的第三方产品由 Microsoft 以外的其他公司提供。 Microsoft 不对这些产品的性能或可靠性提供任何明示或暗示性担保。