我需要将本地SQL Server 2017数据库迁移到Azure SQL数据库，并且由于要克服很多限制，因此我面临一些挑战。 特别是，由于Azure SQL数据库仅在UTC时间（无时区）工作，并且我们需要本地时间，因此我们必须更改数据库中GETDATE() 所有地方的使用方式，事实证明，这比我预期的要多。 我创建了一个用户定义的函数，以获取在我的时区正确工作的本地时间： CREATE FUNCTION [dbo].[getlocaldate]() RETURNS datetime AS BEGIN DECLARE @D datetimeoffset; SET @D = CONVERT(datetimeoffset, SYSDATETIMEOFFSET()) AT TIME ZONE 'Pacific SA Standard Time'; RETURN(CONVERT(datetime,@D)); END 我遇到的问题是实际上GETDATE()在每个视图，存储过程，计算列，默认值，其他约束等中都使用此函数进行了更改。 实施此更改的最佳方法是什么？ 我们正在受管实例的公开预览中。与仍然存在相同的问题GETDATE()，因此对解决此问题没有帮助。迁移到Azure是必需的。始终在该时区使用（并将使用）此数据库。
考虑SQL Server 2014中的以下查询计划： 在查询计划中，自联接ar.fId = ar.fId产生的估计值为1行。但是，这在逻辑上是不一致的估计：ar只有20,608行，并且只有一个不同的值fId（准确地反映在统计数据中）。因此，此联接产生行（~424MMrow）的全叉积，导致查询运行几个小时。 我很难理解为什么SQL Server会提出一个很容易证明与统计数据不一致的估计。有任何想法吗？ 初步调查和其他细节 根据Paul 在这里的答案，似乎用于估计联接基数的SQL 2012和SQL 2014启发式方法应该可以轻松处理需要比较两个相同直方图的情况。 我从跟踪标志2363的输出开始，但无法轻松理解。下面的代码段是否表示SQL Server正在比较的直方图fId和bId以便估计仅使用的联接的选择性fId？如果是这样，那显然是不正确的。还是我误读了跟踪标志输出？ Plan for computation: CSelCalcExpressionComparedToExpression( QCOL: [ar].fId x_cmpEq QCOL: [ar].fId ) Loaded histogram for column QCOL: [ar].bId from stats with id 3 Loaded histogram for column QCOL: [ar].fId from stats with id 1 Selectivity: 0 请注意，我想出了几种变通办法，这些变通办法包含在完整的repro脚本中，并将此查询缩短为毫秒。这个问题的重点是了解行为，如何在以后的查询中避免它，以及确定它是否应与Microsoft一起提交。 …
我正在努力实现以下目标： California | Los Angeles, San Francisco, Sacramento Florida | Jacksonville, Miami 不幸的是，我正在“洛杉矶，旧金山，萨克拉曼多，杰克逊维尔，迈阿密” 我可以使用STUFF函数获得所需的结果，但是想知道是否有使用COALESCE的更干净的方法？ STATE | CITY California | San Francisco California | Los Angeles California | Sacramento Florida | Miami Florida | Jacksonville DECLARE @col NVARCHAR(MAX); SELECT @col= COALESCE(@col, '') + ',' + city FROM tbl where city = …