嗨，朋友们
，我有一个应用程序可以在数据库中存储数千个文本文件，每个文件平均大小为 3KB。另一个表存储有关他们更频繁搜索的简要信息。有 140,000 条记录，我的数据库性能变得太慢。
我认为我可以将这些文件存储在磁盘上，从而将我的数据库大小减少约 80%。这些文件的存储只是为了显示（读取文件内容和显示），而不是为了对它们进行任何数据库操作。但我的网站有大约 1000 个用户，我担心如果我将这些文件存储在磁盘上，它会变得最糟糕（磁盘 I/O 操作增加，在不同会话中读取文件可能会增加 I/O 来回移动硬盘头加上我无法控制仅在一个线程中读取文件）
有大佬有相关经验吗？
请为我做这个决定。谢谢，谢谢
如果没有更多信息，我建议您更深入地研究性能问题的根源。您的查询是否有效，是否有索引来支持您的查询。
关于将文件存储在数据库中，这很有趣。我只能给出我个人的意见，通常我宁愿将文件存储在磁盘上，只存储对文件的引用，即。数据库中的路径。但是这里有很多优点/缺点需要考虑，一件事是您的备份需要跨越的不仅仅是数据库备份。
我会Please make this decision for me. THANKS THANKS从字面上理解你的评论。
在数据库服务器中安装至少 8 gig 的内存（更好的 SQL 缓存）
将两个磁盘配置为镜像，并将应用程序数据库的日志文件放在镜像上。不要压缩此磁盘（更快的日志文件写入）
将4个磁盘配置为Raid 10，并将db放在Raid 10上。不要压缩这个磁盘（比raid 5更好的读取性能）
将单个磁盘配置为 tempDB 的位置。不要压缩此磁盘（隔离 tempDB 的活动）
在服务器上仅运行 SQL Server。
通过检查缺少的索引动态管理视图，确保您的数据库具有正确的索引。
确保您的数据库有一个维护计划以减少数据库和索引碎片
从数据库中提取并重新加载每个“文本”文件。在加载文本文件之前，使用您选择的工具压缩 (zip) 文件。将“文本”文件存储在 varbinary 数据类型中。将应用程序配置为在显示之前解压缩文件（减少 SQL 的磁盘 IO 以存储“文本”和网络 io 到客户端）
使用已知数量的用户和搜索对您的应用程序进行基准测试
在客户端使用期间将您的基准与实际值进行比较
定期监控磁盘等待、网络 IO 和内存。
如果您的性能仍然很差，请聘请 SQL DBA 来评估您的系统。我相信这个网站上的 performanceDBA 是从事合同业务的。