我的数据库有一个非常大的表，超过20亿行，有3列。 Id（uniqueidentity），Type（int，0-10.0 =最常用.10 =最少使用），数据（1-10MB之间的二进制数据）
我可以通过哪些方法优化此数据库？ （主要是选择查询）
*注意：我稍后可能会在此表中添加更多列（例如：location，date ...）
答案 0 :(得分：5)
假设id列是聚集索引键，并假设uniqueidentity表示uniqueidentifier：
uniqueidentifier类型吗？为什么？ 对于群集密钥，GUID是一个众所周知的糟糕选择。有关更详细的讨论，请参阅GUIDs as PRIMARY KEYs and/or the clustering key：
但是，GUID不是顺序的 - 就像有价值观的人一样 在客户端生成（使用.NET） 或者由newid（）函数生成 （在SQL Server中）可能非常糟糕 选择 - 主要是因为 它创造的碎片化 基表也因为它 尺寸。这是不必要的宽（它是4 时间宽于基于int的身份 - 它可以为您提供20亿（真正的，40亿）唯一行。和， 如果你需要超过20亿 总是可以使用bigint（8字节 int）并得到2 ^ 63-1行
另请阅读Disk space is cheap...That's not the point!作为后续内容。
除此之外，您需要完成作业并发布此类问题所需的详细信息：完全表和索引定义，流行数据访问模式（按键，按范围，过滤排序顺序，加入等等）。
到目前为止，您是否已做过任何确定问题的工作？如果没有，请从Waits and Queues开始，这是一种经过验证的方法，可以识别性能瓶颈。一旦您衡量并找到需要改进的地方，我们就可以建议如何改进。
答案 1 :(得分：1)
添加索引。确定哪个列是最合适的聚簇索引。
决定在每个（小的）行中存储10MB的二进制数据是否可以很好地利用数据库
[更新以回应Remus的评论]