首先，我不是数据库专家，而是承包商。我聘请了一名（优秀的）程序员，但由于我们遇到的一些问题以及我正在阅读的所有信息，现在对数据库设计的某个部分有一些疑问。让我们开始吧。
我们构建了一个住宅站点，它使用解析器处理所有数据并将其存储在ms-sql数据库中。每天这些Feed包含大约70,000条记录，其中大部分也附有图片（平均3张）。图片大小从30kb到400kb不等。 该数据库具有大约相同数量的记录。大约有400个新对象需要处理。这意味着每天都必须输入数据库中的所有记录，以查看数据是否已更改，对象是否已删除或是否为新对象，因此必须插入。 图片存储在数据库中。这些源在具有32GB内存和SSA磁盘的双四核机器上处理。该数据库现在大小为600GB。
目前，我们每天约有3000名用户查看6个房屋，平均每个用户可以查看10张图片。
这就是我们所经历的： - 整个解析过程大约需要13个小时。 - 我们在日志中遇到很多超时错误 - 我们退出了一些死锁错误 - Google抱怨超时错误，因此索引的页数不多。 - 由于某些目录加载时间超过10秒，谷歌对该网站的评价较慢。
我个人认为它与数据库中的图片和一些不良查询有关。但在我开始向程序员抱怨之前，我想听听你对此的看法。 提前感谢您的时间。
我的程序员更新： 以下是有关表格结构的一些信息。图像有2个表，1个称为imageinfo，用于查询图像（例如获取imageid和content-type的列表）和包含图像id和BLOB的图像表。 imageinfo表具有与图像表（1：1关系）相同的id，并具有一些额外信息，如图像的名称，类型和散列。在解析器进程中使用该哈希来确定图像是否已更改。因此，触摸图像表的唯一时间是从解析器插入/更新/删除并且站点访问图像。 访问和下载一张图像所需的时间约为350毫秒。
答案 0 :(得分：3)
你告诉我们两个问题：
（2）很简单：您可能需要了解您的读取查询并将其编入索引。这绝对是可以解决的。
（1）如果没有更多细节，就更难说些什么。我知道你需要比较大量的blob - 你可以存储除了实际数据之外的那些博客的紧凑哈希。这样您就不需要检索blob以进行比较，甚至可以索引哈希值。
您是否在数据库中有图像？
最大的专业人员是：一致且简单的备份，开发人员的便利性。最大的 con 是潜在的误用。你真的不能说图像属于文件系统。数据库对他们来说通常很好，除非有特定和具体的理由将它们放在其他地方。
我的猜测是，您对这些博客的使用会被滥用，如果文件存储在文件系统中，您会遇到同样的问题。
答案 1 :(得分：0)
你真的需要衡量表现在哪里伤害你。不知道究竟什么是慢的，你不能指望开始修复它。
但是，如果您正在寻找有关从哪里开始测量的想法，那么我会说看看导入过程，看看它在RBAR风格中做了什么。 RBAR代表'Row By Agonizing Row'，恰当地描述了在一行中操作单行的过程，当它们在集合中工作效率更高时。
我要检查的另一件事是你实际上没有检查每个图像的内容以确保它没有改变。如果你正在对这些数据进行二进制比较，我可以想象它会非常慢。如果你为它计算校验和并比较校验和，那么
a）您可以在SQL Server进程之外计算该校验和，最好是在另一个框中
b）您将能够在更精益的流程中检查更新的图像，特别是如果该校验和是合适索引上的INCLUDE列。
但是，正如所评论的那样，将图像存储在数据库中并不是最明智的想法。