小编Jam*_*s D的帖子

从历史上看，作为安全最佳实践的一部分，建议不要使用默认端口连接到 SQL Server。在具有单个默认实例的服务器上，默认情况下将使用以下端口：

• SQL Server 服务 - 端口 1433 (TCP)
• SQL Server Browser 服务 - 端口 1434 (UDP)
• 专用管理连接 - 端口 1434 (TCP)

问题：

• 这个建议还有用吗？
• 是否应该更改上述所有端口？

继承的死锁问题需要帮助！

下面给出的代码似乎已经写了一段时间，试图解决围绕在更大/更胖的 [IDs] 父表上分配新 ID 值的争用问题，首先在较小的 [ID_Stub ] 桌子。然而，持续死锁的存在表明这段代码引起的问题似乎比它解决的问题要多。

我们经常在下表中的 INSERT 语句周围遇到死锁（表名和列名已被混淆）。该表没有触发器或外键依赖项，但具有如下聚簇索引和非聚簇索引。

CREATE TABLE dbo.ID_Stub (
ID int IDENTITY(1,1) NOT NULL,
IDReference nchar(25) NULL,
AdditionalID int NULL,
CreatedBy int NOT NULL,
CreatedOn datetime NOT NULL,
CONSTRAINT PK_ID_Stub PRIMARY KEY CLUSTERED (ID) WITH 
(
    PAD_INDEX = OFF, 
    STATISTICS_NORECOMPUTE = OFF, 
    SORT_IN_TEMPDB = OFF, 
    IGNORE_DUP_KEY = OFF, 
    ONLINE = OFF, 
    ALLOW_ROW_LOCKS = ON, 
    ALLOW_PAGE_LOCKS = ON, 
    FILLFACTOR = 90
)
);
GO

CREATE NONCLUSTERED INDEX idx_IDReference ON dbo.ID_Stub (IDReference) WITH 
(
    PAD_INDEX …

如果这是一个愚蠢的问题，请道歉。我们正在尝试将我们的多语句表值函数 (MSTVF) 转换为内联表值函数 (ITVF)，以避免强制序列化查询。

我有以下 ITVF 函数（淡化了），但执行计划仍然说它的并行度为 1。所讨论的实际函数具有三个由 UNION ALL 分隔的基本 SELECT 语句。

我错过了什么吗？我怎样才能避免在这里强制序列化？

CREATE FUNCTION dbo.Test (@i int)
RETURNS TABLE
AS
RETURN
SELECT @i as [i];
GO

SELECT * FROM dbo.Test (2);
GO

https://www.brentozar.com/pastetheplan/?id=Hyn8o50D7

该实例具有以下设置：

• 并行的成本阈值 = 5
• 最大并行度 = 0