小编Sea*_*ser的帖子

我是一名 PHP 开发人员，所以不要太严格。我有一个大表 ~5.5gb 转储。我们的 PM 决定在其中创建新列以执行新功能。表是 InnoDB 所以我试过：

1. 使用表锁定更改屏幕中的表。花了大约 30 小时，一无所获。所以我只是阻止了它。首先我犯了一个错误，因为我没有结束所有交易，但第二次没有多锁。状态是copy to tmp table。

2. 由于我还需要为此表应用分区，因此我们决定使用相同的名称和新结构进行转储、重命名和制作表。但是转储正在制作严格的副本（至少我没有发现其他东西）。所以我添加了转储一个新列sed并查询它。但是一些奇怪的错误开始了。我相信这是由字符集引起的。utf-8 中的表和文件在sed. 所以我在 30% 的数据上遇到了错误（未知命令 '\''）。所以这也是一种不好的方式。

还有哪些其他选项可以实现这一点并提高性能（我可以使用 php 脚本来完成，但需要很长时间）。INSERT SELECT在这种情况下会有什么表现。

感谢您的任何提前。

磁盘（松散的措辞不仅包括旋转媒体，还包括非旋转媒体 [SSD、NVMe 等]）驱动器在其底层格式和硬件方面不断发展。其中一部分是从 512 字节物理扇区大小到 4k 物理扇区大小的“增强”，这改变了磁盘布局（512n、512e、4kn）。

下一个演变是使用 8k 物理扇区大小，一些制造商开始生产并在生产中设置。鉴于下一步，Windows 是否支持 8k 扇区大小的磁盘？SQL Server 是否关心扇区大小？

我在 Windows NT 6.3 (Build 9600:) 上使用 Microsoft SQL Server 2014 - 12.0.4100.1 企业版（64 位）

我有一个 491 GB 的表，其中有 36 亿行没有主键。我希望添加的主键仅涵盖bigint包含唯一值的单个列。数据库有 477 GB 的可用空间，但这似乎还不够。

尝试添加它失败并出现以下错误：

无法为数据库 '[Redacted]' 中的对象 'dbo.SORT 临时运行存储：424251614560256' 分配空间，因为 'PRIMARY' 文件组已满。通过删除不需要的文件、删除文件组中的对象、向文件组添加其他文件或为文件组中的现有文件设置自动增长来创建磁盘空间。

错误中的数据库名称是我尝试添加 PK 的数据库，而不是“tempdb”，这是我在此类错误中经常看到的。

我正在使用的命令：

ALTER TABLE REDACTED ADD CONSTRAINT [PK_REDACTED] PRIMARY KEY CLUSTERED 
(
    [RedactedId] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO

起初，该命令在 8-9 分钟后失败，然后我的 DBA 将另一个数据文件添加到具有大约 150 GB 可用空间的驱动器上的数据库中。24 分钟后再次运行它失败。这是进步，但我不知道需要多少可用空间，或者添加此索引实际需要多长时间。此数据库中目前有 477 …

让我在这篇文章的序言中说，我在跟踪中遗漏了一些事件，但我已经添加了它们，以便下次发生这种情况时添加它们。

最近，我们在我们的环境中看到了 HADR_SYNC_COMMIT 等待类型的奇怪激增（~40k tran/s）。今天的“事件”发生在凌晨4点58分：

在继续之前，我必须补充一点，我们正在对一个大型审计表进行在线索引维护（从 OLTP 表触发器大量记录到此审计表的意义上进行审计），并且索引重建本身被阻止约 22 秒。显然，这在这个特定实例中发挥了作用，但我不太确定它与 HADR_SYNC_COMMIT 有何关系。此外，我们在白天不进行索引维护时也看到过这种情况发生。

查看跟踪，这是我在主设备上看到的：

...以及辅助设备上的所有内容：

...最后回到主要：

2023 年 12 月 1 日凌晨 4:11 左右再次发生了类似的问题，我相信我明白发生了什么。不幸的是，我没有针对这种情况的扩展事件，但我确实有一些日志记录可以描绘出更清晰的画面。从 2023-12-01 04:10:18.5430090 开始，Ola 的索引维护记录了相关数据库上索引的开始时间。Ola 报告的完成时间为 2023-12-01 04:11:13.9431563，但我相信实际 REBUILD WITH ONLINE = ON 完成的时间要早​​得多。

在查看 DPA 时，我注意到 pagelatch_sh 和 pagelatch_ex 等待时间在凌晨 4:11:03-4:11:04 出现峰值：

紧接着这些等待，同一个查询开始看到 HADR_SYNC_COMMIT，并且这些相同的等待在凌晨 4:11:13-4:11:14 完全消失，这正是 Ola 报告索引完成的时间。我的假设是索引 REBUILD 是在凌晨 4:11:03 提交的（大约需要 45 秒的工作），这导致同一数据库中的不相关 INSERT 查询只是等待所有这些日志块在辅助数据库上硬化。一旦索引完成，剩余的日志块就会立即硬化，因为它们只是微小的插入。

CREATE TABLE Table_1 (
    Id INTEGER PRIMARY KEY  AUTOINCREMENT  NOT NULL ,
    EmailId VARCHAR
)

INSERT INTO Table_1 VALUES (1,'raj@gmail.com');
INSERT INTO Table_1 VALUES (3,'test@gmail.com');
INSERT INTO Table_1 VALUES (4,'false5@gmail.com');
INSERT INTO Table_1 VALUES (7,'false55@gmail.com');
INSERT INTO Table_1 VALUES (8,'falsefalse@gmail.com');
INSERT INTO Table_1 VALUES (9,'true1@gmail.com');
INSERT INTO Table_1 VALUES (11,'true2@gmail.com');
INSERT INTO Table_1 VALUES (12,'falsefalsefalse@gmail.com');
INSERT INTO Table_1 VALUES (13,'ravi@gmail.com');
INSERT INTO Table_1 VALUES (14,'rak@gmail.com');
INSERT INTO Table_1 VALUES (15,'false@gmail.com');
INSERT INTO Table_1 VALUES (16,'false66@gmail.com');


CREATE TABLE Table_2 (
    Id …

下面的查询看似简单明了，但却产生了意想不到的结果。

CREATE TABLE #NUMBERS
(
    N BIGINT
);

INSERT INTO #NUMBERS VALUES
(1),
(2),
(3),
(4),
(5),
(6),
(7),
(8),
(9)
;



WITH
A AS
(   
    -- CHOOSE A ROW AT RANDOM
    SELECT   TOP 1 *
    FROM     #NUMBERS            
    ORDER BY NewID()           
),
B AS
(
    SELECT A.N AS QUANTITY, 'METERS' AS UNIT FROM A
    
    UNION ALL

    SELECT A.N*100 AS QUANTITY, 'CENTIMETERS' AS UNIT FROM A
    
    UNION ALL

    SELECT A.N*1000 AS QUANTITY, 'MILLIMETERS' AS UNIT FROM A
    
    UNION ALL

    SELECT A.N*1000000 …