小编Dan*_*aar的帖子

我们有一个FILESTREAM包含几百万个文件的容器，我们相信这是我们遇到的性能问题（大量超时）的原因。

根据这个关于FILESTREAM最佳实践的博客，每个容器不应超过 300,000 个文件。

根据此处接受的答案，除非将表重新创建到新FILESTREAM位置，否则无法完成它。

1. 我的情况是这样吗？
2. 如果是这样，确保每 300,000 个文件自动创建足够的容器来处理此问题而无需手动干预的推荐方法是什么？

表的结构如下：

CREATE TABLE [dbo].[Documents](
    [ContentPath] [uniqueidentifier] ROWGUIDCOL  NOT NULL,
    [FileContent] [varbinary](max) FILESTREAM  NULL,
 CONSTRAINT [UQ_IX_Documents_ContentPath] UNIQUE NONCLUSTERED 
(
    [ContentPath] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 90) ON [PRIMARY]
) ON [PRIMARY] FILESTREAM_ON [FSFileGroup_1]

我们使用的是 SQL Server 2012。不幸的是，不是 Enterprise（我们最近才意识到它支持每个文件组多个容器）。

尽管我们从不进行记录更新，但我们进行了大量写入，可能与读取一样多。模式是：一次一个，由 ContentPath 读取，并且没有特定的容器或顺序写入。