我正在经历期刊Azure SQL数据库连接速度缓慢。根据{{3}}文章中的建议，我运行了sys.dm_db_wait_stats（类似于{1}}的Azure SQL数据库）聚合脚本，该脚本向我显示最长等待类型为sys.dm_os_wait_stats。平均等待时间 54秒。
XE_FILE_TARGET_TVF在Wait statistics, or please tell me where it hurts中未提及我所知道的任何其他在线资源。我怀疑“XE”表示“扩展事件”，“TVF”表示“表值函数”，“FILE_TARGET”可能表示正在将某些内容写入某个文件。
那么，它是什么样的等待？
答案 0 :(得分：3)
使用Azure SQL Database Query Performance Insight对SQL Azure数据库进行故障排除。首先，单独等待统计数据不是一种正确的性能故障排除方法。阅读How to analyse SQL Server performance以获得更全面的方法，学习分析CPU的使用位置，而不仅仅是花费等待的时间。汇总等待统计数据通常会产生误导，过滤掉“良性”等待数据。等待统计数据是追逐红灯游戏。
不幸的是，在SQL Azure数据库环境中并非一切都可行。从查询性能洞察开始，看看您是否可以将性能问题与应用程序发出的查询相关联。使用SQL Database Index Advisor获取工作负载的索引建议。
如果找不到应用程序问题并怀疑这是由平台引起的，则必须打开支持案例。 Twitting @AzureSupport在获得帮助方面非常有效。
回答您的问题：许多Azure SQL DB监控都依赖于扩展事件，并将数据存储到文件中。此特定等待数据不太可能与您的性能问题的原因有关。
答案 1 :(得分：0)
我相信这是一个异步过程，所以可能无需担心，可能是一个红鲱鱼。但是我认为这是DB背后的结构相关任务。这个事件似乎一直导致你的问题吗？