我们为 TempDB 安装了专用的 SSD 驱动器
- 第一个问题 - 这些驱动器是否应该使用 64 Kb 分配大小进行格式化？目前它显示 4 Kb（每个集群的字节数 = 4096）
TempDB 是否受益于 64 Kb 单元大小，或者可以保留默认的 4 Kb？
- 第二个问题 - 我们在一个单独的“虚拟”卷上拥有数据和日志文件，这些卷是 SAN 管理员之前切片的，这些卷是由 SAN RAID 阵列制成的，并显示 4 Kb 分配单元大小
此时我们无法更改这些卷的分配单元大小。因此，如果我们将 TempDB SSD 驱动器更改为 64 Kb，并且数据/日志卷保持为 4 Kb，是否会对 SQL Server 造成任何麻烦？
绝对将其格式化为 64k .. tempdb 将比其他 san 数据文件更快且负担更少。因素可能很多，但主要因素是 tempdb 的大量使用。SQL Server 按照设计以 64k 的倍数分配空间，Win Server 也是如此。
在其自己的 64k 格式化驱动器上写入正确预分配的数据文件对性能非常重要。64k 块将从 16x4k 数据文件读取到 1x64k 数据包写入中的 tempdb，而不是 16k 数据包写入。除非有很多碎片，否则读取 san 驱动器上的 4k 分配真的不是一个大问题，4k San 会影响写入。这就是数学真理。然而从理论上讲，即使在 4k 时，经过适当突袭的 San 也可能不会那么引人注目，因为考虑到他们正在写入的驱动器磁头倍数。
除此之外，您还可以使用架构修改，例如让 tempdb 使用多个相等的数据分区。但这可能超出了范围。
这是我的简短回答，希望我没有因为简短而混淆这个问题。