我注意到我们的 (Hitachi) SAN 以 42MB 块处理数据。它是分层存储，因此当 director 决定何时应该将存储提升/降级为更快/更慢的存储时，每个块都会被评估。在没有将特定 LUN“固定”到特定层的政治权重的情况下，我正在尽我所能来设置我的 SQL Server (2008 R2 Enterprise) 实例以取得成功。
因此，我想知道将我的文件大小和文件增长大小更改为 42 的倍数是否会有任何好处/损害？示例数据库将SIZE=57886MB带有FILEGROWTH=5124MB.
我看到了额外读取的可能性（因为 (42*1024)/8 = 8601.6，但是 (42*1024)/64 = 672）但我不确定我是否完全掌握了这里的所有概念。
42MB 单元（Hitachi 也将此称为页面，多么方便）。是将空间分配给 LUN 的基本分配单元。因此，使用动态配置，LUN 将始终以 42MB 的步长增长。这些 Hitachi 42MB 页面取自池中的不同阵列组。
因此，只要 LUN 需要更多空间，就会分配一个新的 42MB Hitachi 页面。当您将第一个 8KB SQL 数据页写入文件时，将分配一个 42MB 的日立页。SQL 数据页的后续写入将进入这个 42MB 区域，直到它被填满。
现在，重要的是要了解一个 42MB 的页面进入一个奇偶校验 raid 组。如果您有小型 RAID 组，例如：RAID-1+0: 2D+2P (2+2)（4 个磁盘）并且您的数据访问主要是顺序的，那么当您只有一个文件时，这可能是个问题。
假设您有 4 个 RAID10 组，每个组有 4 个磁盘。您恰好只有 1 个重要的表，其中包含 1 个大小为 168MB 的聚簇索引。
当你开始插入这个表时，第一个 42MB 分配页将被放置在一个 RAID 组中，一旦这 42MB 已满，第二个分配页将被分配到另一个 RAID 组中，很可能所有 4 个 42MB 分配页将被分配分为 4 个 RAID 组。（为简单起见，我们目前不包括分层）。
需要了解的重要一点是，您按照聚集键的顺序依次执行的任何操作在任何给定时刻都将只有 4 个磁盘来处理 IO。（如果你正在写 2 个磁盘......）即使整个表分布在 16 个磁盘上......
如果您想使用所有 16 个磁盘。您必须在文件组中创建 4 个文件（在 4 个单独的 LUN 上）并在其上创建表。至少您现在知道 SQL 正在“跨 4 个 42 MB 分配页分割数据”
这对于事务日志文件来说可能是最有问题的。它只有 1 个文件并且是连续的。您在这里可以做的唯一“调整”是使该池中使用的 RAID 组尽可能大。矛盾的是，一个串联的阵列组 RAID5 14+2 或 RAID5 28+4 可能是最快的，即使它是 RAID5 而不是 RAID 10，因为据我所知，RAID 10 中可以创建的最大 RAID 组是 4+4 8个磁盘。
请注意，如果您运行的服务器具有多个数据库且多个 LUN 共享同一个池，或者更通用的多个服务器都在同一个池中具有 LUNS，那么这将变得不那么重要。很明显，一般负载将均匀分布在所有 raid 组中。
关于分层，我不会从性能目标上担心它。（如果不允许 pin..） 42MB 的重分配页面被移动到高性能层，因此您可能会遇到一个表分布在 3 个不同层的情况。Apperently 你有你的表的部分是 IO 密集型和部分不是......
担心小型 raid 组和单个文件（实际上是单个 LUN）和（高增量插入或大量表本地化更新/删除或大量连续读取）的组合
希望这个对你有帮助..
进一步阅读：
Hitachi Tiering 设计指南
日立 SQL Server 最佳实践
关于 42 分配单元的博文