Sql server 包含数百万个文件的SQL Server FILESTREAM文件表

我只是想问一下，设计一个将来可以容纳500-1500万个最大0.5-10mb文件的文件表是否安全

NTFS能处理吗

我曾经在旧的Windows Server 2008 R2上遇到过一个问题，当我有一个包含250多万个文件的文件夹时，在该文件夹中创建一个新文件大约需要30秒。。。。获取文件列表大约需要5分钟。这是NTFS的问题吗

这会是个问题吗？或者文件流/文件表本身会创建子文件夹来处理如此多的文件等

或者禁用8.3命名约定就足够了，这样就可以正常工作了

谢谢和问候

NTFS能处理吗

---

对。只是不要打开文件资源管理器。程序，而不是操作系统，也不能处理这个问题。不尝试将所有文件加载到列表中的命令行或服务器运行良好。

根据我的经验，简而言之，是的，NTFS可以处理它，但避免探索FILESTREAM目录（资源管理器无法处理这一卷文件，它会崩溃）。一些白皮书建议在文件大小为256KB或更大时使用FileStream，但在大于1MB的文件中，其性能是显而易见的

以下是为最佳实践推荐的一些技巧：

• 禁用索引服务（禁用NTFS卷上的索引 存储FILESTREAM数据的位置。）
• FileStreamfilegroup的多个数据文件位于单独的卷中
• 配置正确的NTFS群集大小（建议64KB）
• 正在配置防病毒软件（无法删除FILESTREAM的某些文件，否则数据库将损坏）
• 禁用上次访问时间属性
• 定期磁盘碎片整理
• 禁用短文件名（8dot3）
• 将FILESTREAM数据容器保留在单独的磁盘卷（mdf、ndf）上 和日志）

现在，我们正在做一些测试，以将我们的FileUpload数据库（8TB，记录数为25MM）从varbinary（max）迁移到FileTable。我们的方法是每年在一个数据库中拆分一个非常大的数据库

我想知道您目前是否正在生产环境中进行此项工作，并了解您的经验

---

你可以在一本免费电子书中找到更多信息：

你能告诉我大于1MB文件的百分比吗？>50%你为什么要问？这有关系吗因为您最终可以得到一些混合解决方案—在数据库中存储小文件，在文件流中存储大文件，或者如果所有文件都很小，将它们存储在数据库中好的，谢谢，但假设我只想要这个文件流/文件表使用-它能处理即时消息指向的情况吗？你能在类似的环境中测试吗-你能生成500万条虚拟记录并自己测试吗？这是最有把握的方法。所以我在第一篇文章“然后在文件夹中创建一个新文件花了大约30秒”中提到的这个问题与NFT无关？我是用编程的方式创建这个新文件的，不需要做dir等？