因为我真的想从我可用的硬件(大约64GB的RAM,一个非常快的SSD和16个内核)中挤出最后一滴性能,我想要允许每个表都有自己的文件,这样无论是否我正在加入2,3,4,5或更多表,每个表将始终使用单独的线程读取,每个文件的结构将与表内容紧密对齐,这有望最大限度地减少碎片并使其更快用于sql Server添加到任何给定表的内容.
有一点需要注意,我坚持使用sql Server 2008 R2 Web Edition.这意味着我不能使用自动水平分区,它将其作为性能增强进行规则.
每个表使用一个文件实际上会最大限度地提高性能,还是我忽略了内置的sql Server引擎特性会使这样做多余？
其次,如果每个表使用一个文件是有利的,为什么create table只给我选择将表分配给文件组而不是特定的逻辑文件？这需要我为我的场景中的每个文件创建一个单独的文件组,这告诉我,sql Server可能没有想到我假设的优势来自于我提出的建议.
解决方法
I was thinking of allowing each table to have its own file so that no
matter if I’m joining on 2,5 or more tables,each table will
always be read using a separate thread and the structure of each file
will be closely aligned with the table contents,which would hopefully
minimise fragmentation and make it faster for sql Server to add to the
contents of any given table
你在说什么？不确定从哪里获得您的信息,但您当然应该丢弃该来源.你在这里假设的一切都是正确的.
如果您想阅读有关sql Server的SSD性能的详细讨论,那里有几个博客系列.通常情况下,保罗兰达尔的最佳读物是：
> Benchmarking: Introducing SSDs (Part 1b: not overloaded log file array)
> Benchmarking: Introducing SSDs (Part 1: not overloaded log file array)
> Benchmarking: Introducing SSDs (Part 2: sequential inserts)
> Benchmarking: Introducing SSDs (Part 3: random inserts with wait stats details)
> Benchmarking: Multiple data files on SSDs (plus the latest Fusion-io driver)
布伦特也有一个关于这个主题的精彩演讲：SQL on SSDs: Hot and Crazy Love还有更多.
通过所有这些演示文稿,您将很快注意到它们都专注于写入,因为这是SSD性能出现的地方.你的帖子几乎完全是关于阅读,这是一个不同的主题.如果读取是你的痛点,那么你应该谈论RAM,而不是关于SSD,以及正确的索引和查询策略.
