你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

查询一致性

查询一致性是指查询和更新的同步方式。有两种受支持的查询一致性模式：

强一致性：强一致性可确保对最近更新（如数据追加、删除和架构修改）的即时访问。强一致性是默认的一致性模式。由于同步，此一致性模式在并发方面的表现略逊于弱一致性模式。
弱一致性：使用“弱一致性”时，在查询结果反映最新数据库更新之前可能有延迟。此延迟范围通常在 1 到 2 分钟之间。弱一致性可以支持比强一致性更高的查询并发率。

例如，如果每分钟将 1000 条记录引入数据库中的一个表中，则对该表以强一致性运行的查询将能够访问最近引入的记录，而对该表以弱一致性运行的查询可能无法访问最近几分钟的某些记录。

注意

默认情况下，查询以强一致性运行。建议仅在需要支持更高的查询并发性时切换到弱一致性。

强一致性用例

如果对近几分钟内数据库中发生的更新具有强依赖性，请使用强一致性。

例如，以下查询计算 5 分钟内的错误记录数，并触发计数大于 0 的警报。此用例最好用强一致性处理，因为见解可能会更改，导致你无权访问近几分钟引入的记录，而弱一致性可能就是这种情况。

my_table
| where timestamp between(ago(5m)..now())
| where level == "error"
| count

此外，当数据库元数据较大时，应使用强一致性。例如，数据库中有数百万个数据区，使用弱一致性会导致查询头从永久存储中下载和反序列化大量元数据项目，这可能会增加下载和相关操作中暂时失败的可能性。

如果对近几分钟内数据库中发生的更新没有强依赖性，并且需要较高的查询并发性，请使用弱一致性。

例如，以下查询计算过去 90 天内每周的错误记录数。弱一致性适用于这种情况，因为你的见解不太可能受到影响，过去几分钟引入的记录将被忽略。

my_table
| where timestamp between(ago(90d) .. now())
| where level == "error"
| summarize count() by level, startofweek(Timestamp)

下表总结了弱查询一致性的四种模式。

“模式”	说明
随机	将查询随机路由到群集中可用作弱一致查询头的节点之一。
相关性（按数据库）	同一数据库中的查询将会路由到相同的弱一致查询头，确保该数据库的一致执行。
相关性（按查询文本）	具有相同查询文本哈希的查询将会路由到相同的弱一致查询头，这有助于利用查询缓存。
相关性（按会话 ID）	具有相同会话 ID 哈希的查询将会路由到相同的弱一致查询头，确保会话内的一致执行。

可以通过发送请求的客户端或使用服务器端策略来指定查询一致性模式。如果未通过上述任一方式指定，则会应用默认的强一致性模式。

发送请求的客户端：使用 queryconsistency客户端请求属性。此方法为特定查询设置查询一致性模式，不会影响由默认策略或服务器端策略确定的总体有效一致性模式。有关详细信息，请参阅客户端请求属性。
服务器端策略：使用查询一致性策略的 QueryConsistency 属性。此方法在工作负荷组级别设置查询一致性模式，这使用户无需在其客户端请求属性中指定一致性模式，并允许强制实施所需的一致性模式。有关详细信息，请参阅查询一致性策略。

注意

如果使用 Kusto .NET SDK，可以通过连接字符串设置查询一致性。此设置将应用于通过该特定连接字符串发送的所有查询。有关详细信息，请参阅连接字符串属性。