标签: sql-server

我有一个 SQL 语句，该语句将行插入到表中，并且在 TRACKING_NUMBER 列上具有聚集索引。

例如：

INSERT INTO TABL_NAME (TRACKING_NUMBER, COLB, COLC) 
SELECT TRACKING_NUMBER, COL_B, COL_C 
FROM STAGING_TABLE

我的问题是 - 在聚集索引列的 SELECT 语句中使用 ORDER BY 子句是否有帮助，或者是否会因 ORDER BY 子句所需的额外排序而否定任何获得的收益？

当今存在的在 Windows Server 上执行 Microsoft SQL Server 负载平衡并对任何编程访问透明的方法。这是内置的还是必须购买解决方案？

我试图找出今天是否有一个解决方案，从 Web 服务器或其他数据库访问 SQL Server 的角度来看，它使这变得非常容易。

我有一个现有的表：

CREATE TABLE dbo.ProofDetails
(
    ProofDetailsID int NOT NULL 
        CONSTRAINT PK_ProofDetails 
        PRIMARY KEY CLUSTERED IDENTITY(1,1)
    , ProofID int NULL
    , IDShownToUser int NULL
    , UserViewedDetails bit NOT NULL 
        CONSTRAINT DF_ProofDetails_UserViewedDetails 
        DEFAULT ((0))
);

该表有 150,000,000 行。系统 24x7x365 全天候运行，因此没有定期发生的维护窗口。

我想向表中添加索引，并且使用 SQL Server 的企业版，我应该能够在不阻止对表的写访问的情况下做到这一点。我使用的命令是：

CREATE INDEX IX_ProofDetails_ProofID_Etc 
ON dbo.ProofDetails (ProofID, IDShownToUser)
INCLUDE (UserViewedDetails)
WITH (ONLINE=ON
    , ALLOW_ROW_LOCKS=ON
    , ALLOW_PAGE_LOCKS=ON
    , FILLFACTOR=100
    , MAXDOP=4
);

我在 SSMS 中通过按 自行执行了该语句F5。它运行了超过一分钟，然后开始阻塞其他会话。然后我立即取消了该CREATE INDEX命令，因为我无法阻止其他会话。

在第一分钟，没有任何东西阻止我的CREATE INDEX命令，sys.dm_exec_requests显示了等待类型CXPACKET- 当然。我认为这不是一件坏事，因为操作是并行化的。 …

我正在努力实现以下目标：

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 = 'California';
SELECT @col;

谢谢

• 主要浏览器正在超越 SSL3.0 和 TLS1.0 。
• PCI 安全委员会已宣布将这些协议视为足够强的加密的终止日期。

我们需要摆脱这些协议，使用更新更强的协议。在 Windows 服务器上，您可以非常轻松地禁用这些旧协议，而仅提供 TLS1.1 或更高版本。但是，正如其他地方所述，如果禁用了这些较低的协议，Microsoft SQL Server 2008 R2 和 SQL Server 2012（至少是标准版）都将无法启动。但是，MS SQL Server 的版本越来越多。有 SQL Server Standard、Business Intelligence、Enterprise、Express、Web 和 Compact 版本。当然还有 SQL Server 2008、2012、2014 和（预发布）2016。

这些版本中哪些支持或将仅支持使用 TLS1.1 或更高版本的协议？

我已经研究这个僵局问题好几天了，无论我做什么，它都以一种或另一种方式持续存在。

首先，一般前提：我们有访问与访问项的一对多关系。

访问项目相关信息：

CREATE TABLE [BAR].[VisitItems] (
    [Id]                INT             IDENTITY (1, 1) NOT NULL,
    [VisitType]         INT             NOT NULL,
    [FeeRateType]       INT             NOT NULL,
    [Amount]            DECIMAL (18, 2) NOT NULL,
    [GST]               DECIMAL (18, 2) NOT NULL,
    [Quantity]          INT             NOT NULL,
    [Total]             DECIMAL (18, 2) NOT NULL,
    [ServiceFeeType]    INT   NOT NULL,
    [ServiceText]       NVARCHAR (200)  NULL,
    [InvoicingProviderId] INT   NULL,
    [FeeItemId]        INT             NOT NULL,
    [VisitId]          INT             NULL,
    [IsDefault] BIT NOT NULL DEFAULT 0, 
    [SourceVisitItemId] INT NULL, 
    [OverrideCode] INT NOT NULL DEFAULT 0, 
    [InvoiceToCentre] BIT NOT …

回顾这个问题，似乎不需要做很多工作。他们试图用日期扩展范围。在其他数据库中，您只需使用greatest和least..

least(extendDate,min), greatest(extendDate,max)

当我尝试使用这些时，我得到

'least' is not a recognized built-in function name.
'greatest' is not a recognized built-in function name.

这将涵盖任一方向的扩展。

就问题而言，您仍然需要进行排他性范围替换。

我只是想知道 SQL Server 用户如何实现查询模式来模仿least和greatest功能。

• PostgreSQL GREATEST/LEAST
• MySQL GREATEST/LEAST
• 玛丽亚数据库 GREATEST LEAST
• 数据库2 GREATEST LEAST
• 甲骨文 GREATEST LEAST

您是否将条件展开到CASE语句中，或者是否存在启用此功能的 Microsoft 的扩展、第三方加载项或许可？

我能够重现一个我认为出乎意料的查询性能问题。我正在寻找一个专注于内部的答案。

在我的机器上，以下查询执行聚集索引扫描并花费大约 6.8 秒的 CPU 时间：

SELECT ID1, ID2
FROM two_col_key_test WITH (FORCESCAN)
WHERE ID1 NOT IN
(
N'1', N'2',N'3', N'4', N'5',
N'6', N'7', N'8', N'9', N'10',
N'11', N'12',N'13', N'14', N'15',
N'16', N'17', N'18', N'19', N'20'
)
AND (ID1 = N'FILLER TEXT' AND ID2 >= N'' OR (ID1 > N'FILLER TEXT'))
ORDER BY ID1, ID2 OFFSET 12000000 ROWS FETCH FIRST 1 ROW ONLY
OPTION (MAXDOP 1);

以下查询执行聚集索引查找（唯一的区别是删除FORCESCAN提示），但需要大约 18.2 秒的 CPU 时间：

SELECT ID1, ID2
FROM two_col_key_test
WHERE ID1 …

我经常需要对没有正确索引的大表运行查询。所以我要求 DBA 创建这样的索引。他做的第一件事是查看表统计信息并查看索引空间大小。

通常他会告诉我寻找替代解决方案，因为“索引已经大于表”。他觉得索引必须比数据小，因为，他告诉我“你见过书里的索引吗？它比书本身小得多，表索引应该是这样的”。

我不认为他的哲学是正确的，但我不能挑战他，因为他是一名首席 DBA 而我是一名开发人员。我觉得如果一个查询需要一个索引，就应该创建索引，而不是寻找只会使 SP 变得不可读和不可维护的“解决方法”。

我只选择所需的列。问题是我按日期过滤，因此引擎必须进行表扫描以匹配列。该查询每天在晚上运行一次以收集统计信息，但运行需要 15 分钟（我们还有另一个硬性规定：任何过程都不应超过 3 分钟）。

DBA 向我展示了索引统计信息。该表上大约有 10 个索引，其中仅使用了 6 个（统计数据显示其中 4 个的命中率为零）。这是一个有 20 多个开发人员参与的大型系统。无论出于何种原因创建索引，可能不再使用。

我们需要支持 SQL Server 2008，因为这是运行测试数据库的。但客户都在 2014 年和 2016 年。

以下面的例子为例：

SELECT <CalculationA> As ColA,
       <CalculationB> As ColB,
       <CalculationA> + <CalculationB> As ColC
FROM TableA

CalculationA 和CalculationB 会分别计算两次吗？
或者优化器是否足够聪明来计算一次并使用结果两次？

我想进行测试以查看自己的结果，但是，我不确定如何检查这样的事情。

我的假设是它会执行两次计算。
在哪种情况下，根据所涉及的计算，使用派生表或嵌套视图会更好吗？考虑以下：

SELECT TableB.ColA,
       TableB.ColB,
       TableB.ColA + TableB.ColB AS ColC,
FROM(    
      SELECT <CalculationA> As ColA,
             <CalculationB> As ColB
      FROM TableA
    ) As TableB

在这种情况下，我希望计算只执行一次？

请问有人可以证实或反驳我的假设吗？或者指导我如何为自己测试这样的东西？

谢谢。