我们有标准 S0 层 (10DTU) 的 Azure SQL 数据库，一张表有超过 400 万行，并且已正确索引。 这是一个测试/开发环境，只有我在使用这个应用程序。 在某个 X 时间段后，对该数据库/表的第一次请求具有小数据集请求超时！？ 那时 DTU 百分比为 100%，但经过几次请求后，一切都可以完美地满足相同的请求（以及更大的数据集 - DTU 最多为 10-20% 以供大量使用）。 附上最大 DTU 单位的图片。
除了升入更高的薪酬级别之外，您还有什么建议吗？
新... 现在这是用于测试的相同数据库，无需任何后端连接！
从 SSMS 测试
几个小时不活动后的第一次查询（执行时间为 3 分钟）
第二次相同查询（执行时间为12秒）！！！！
有什么想法吗！？
【问题讨论】：
它的行为类似于无服务器数据库。
当然，Azure SQL 数据库是 SQL Server 实例的虚拟化，所以不要指望它会像您的本地一样工作。
我建议你尝试其他家庭版本，如 S1 并测试。性能可能会提高。
也试试
也许你可能需要设置这个场景来自动唤醒你的数据库
【讨论】：
限制可能是导致此问题的原因。发生限制时，您通常会看到您描述的症状、连接超时、性能不佳。
您可以通过以下查询查看连接超时：
select *
from sys.event_log
where event_type <> 'connection_successful' and
start_time >= CAST(FLOOR(CAST(getdate() AS float)) AS DATETIME)
order by start_time desc
以下查询会告诉您何时需要扩大规模。
SELECT
(COUNT(end_time) - SUM(CASE WHEN avg_cpu_percent > 80 THEN 1 ELSE 0 END) * 1.0) / COUNT(end_time) AS 'CPU Fit Percent',
(COUNT(end_time) - SUM(CASE WHEN avg_log_write_percent > 80 THEN 1 ELSE 0 END) * 1.0) / COUNT(end_time) AS 'Log Write Fit Percent',
(COUNT(end_time) - SUM(CASE WHEN avg_data_io_percent > 80 THEN 1 ELSE 0 END) * 1.0) / COUNT(end_time) AS 'Physical Data Read Fit Percent'
FROM sys.dm_db_resource_stats
--service level objective (SLO) of 99.9% <= go to next tier
当 avg_log_write_percent 为 100% 或接近 100% 时，就会发生节流。在开始 IO 密集型工作负载之前尝试扩展层级。
尝试对您的 IO 工作负载实施批处理以控制这些 DTU 峰值。请阅读this 文档了解如何操作。
此外，请尝试按照here 的说明在您的应用程序上实现重试逻辑。
【讨论】：