我想知道如果我们把SQL Server数据库日志文件和tempdb放在RAID 1上，应该用64K群集格式化以获得更好的性能？
目前数据库和日志文件是在RAID5上，我认为如果你在做大量的插入操作的时候数据库日志会更糟。
这是针对SQL Server 2005的
RAID 1通常会提供更好的读取性能，但写入性能更差，所以我不会将它用于大量写入的日志和TempDB。 理想情况下，尽可能使用SQL Server的RAID 10。 请参阅： RAID级别和SQL Server 。
关于您的群集大小问题，请参阅SQL Server的磁盘分区alignment最佳实践 ，以获得有关应考虑的所有注意事项的精彩讨论。 文章说，这是SQL 2008年，但它是2005年同样相关。这是最重要的文章：
有两个相关性，当满足时，是获得最佳磁盘I / O性能的基本先决条件。 以下计算的结果必须产生一个整数值：
Partition_Offset÷Stripe_Unit_Size
Stripe_Unit_Size÷File_Allocation_Unit_Size
在这两者中，第一个对于最佳性能来说是最重要的。 下面演示一个常见的错位情况：给定32,256字节（31.5 KB）的起始分区偏移量和65,536字节（64 KB）的条带单元大小，结果为0.4921875。 这不是一个整数; 因此胶印和胶条的尺寸是不相关的。 这与错位是一致的。
但是，1,048,576字节（1 MB）的起始分区偏移量和65,536字节的条带单元大小会生成精确的整数（与整数一致）的结果。
它取决于（像其他所有）在你的数据库。 如果你主要做的是小写，那么你应该使用一个匹配条带大小的分配单元，并确保分区偏移量是条带大小的倍数。 一般来说，更大的条带更快。
RAID 1和RAID 10几乎总是比RAID 5写速度快（RAID 5必须读写的时候，你写的东西比条带大小小，当写入是一个整体条纹，有更less的惩罚作为磁盘与奇偶校验是唯一必须读写的，写回缓冲区将负责处理）。
乔的build议很好， 除非你有充分的理由不这样做，否则我会这样做的。
64K。 日志需要在专用主轴上。 如果连续日志写入被其他活动中断，则会对性能产生不利影响。 如果需要优化性能，请不要将tempdb放在与日志相同的主轴上。