gytnet

在ip中的啊，，，

这还真是一个好办法。。。谢谢收藏了

有道理，我可以去尝试一下

@实际出真知 磁头摆动次数和簇大小有关系吗？ 如果簇太小，造成数据分散，寻址的时间是要增加的。

从理论上看是可行的，不过性能测试方面还真不容易做，没有严密的监控工具没法实施。

用一个想当然的道理也可以说明：硬盘磁头摆16次和摆1次的时间能一样吗？

这是作者的经验分享，没有长时间的观察是得不出来的。一个测试环境，基本上很难看到这种差别。在一个有10个左右的数据库的服务器上，运行一年以后，这种性能差距还是明显的。至于具体数据说明，倒不是我关心的问题，与环境有关，越复杂的环境，提升越明显。

理论与实践总是有差距的，而且实际与实践也有一定差距。 有人说这种做法在测试出来的数据上并不会有什么提升，这是典型的实际与实践的差距了。 什么是实际？简单来说，在两台实际的生产数据库服务器中，一个是4KB，一个是64KB，刚开始用时不会有什么差距，但在运行一段时间（也许一年）以后，你就会看出这两者的差距了。 用另一个角度来看，如果这种方法无效，那磁盘的碎片整理又有什么作用呢？

[quote]Crazy7：针对SqlFileStream做过类似的类似，改成64KB后性能有所提升，但是很小。[/quote] 调侃一下！

针对SqlFileStream做过类似的类似，改成64KB后性能有所提升，但是很小。

觉得有道理，但是这样真的会有性能上的提升吗？需要做专门的测试才能用数字说明问题。我个人感觉性能提升微乎其微，没有必要这么做。

记得有一款“美洲豹”轿车，它的发动机是240马力，可是它轮子的大小与普通轿车无异。 于是乎，有人经过精细的计算，觉得轮子的尺寸应当放大，这样才能完美地发挥机器的动力......

SQL Server推荐数据文件放的NTFS分区是 64KB 的簇，这样有助提高性能。 而且64KB的簇要用系统管理-〉磁盘管理里面格式化才能选择这个簇的大小。 对于数据文件来说，最少都要3MB，因此对于64KB造成的空间浪费完全可以忽略不计。

帮顶！

最近关于性能的话题逐渐多了起来，方方面面林林总总的。看过自己真是感到非常地茫然！(也许我真的该淘汰了) 所谓的性能好与坏，是与实际的应用相辅相成的，哪有什么绝对的高性能与低性能！真有那些令人仰止的高性能，我们用得起吗？ 我感觉现在讨论的话题，就象是探讨在读一本书时，究竟是用干手指翻书，还是用沾唾沫的手指翻书，哪一个快！甚至可以引申出学习效率、时间就是金钱等等的“大是大非”。 当然，要是数钞票，当属沾唾沫快！ 我真是佩服美国的国防部长盖茨，他能力排众议地停掉F22，而大批使用F35......

究竟是您的想当然，还是做过严格的测试？

觉得有道理 这个想法邪恶的 优化到分配上去了哦

难道会自己去check什么东西吗 ？

谢谢分享，解决了我的问题