你们可以建议任何其他方式来维护和查询性能。
eg. select * from mymajortable where date between '2000/10/10' and '2010/10/10'
此查询大约需要15分钟来检索大约10000条记录。
答案 0 :(得分：3)
与使用覆盖索引的查询相比，SELECT *显然效率较低。
第一步：检查查询计划并查找和表扫描以及最省力的步骤（％）
如果您的'日期'列上还没有索引，那么您当然需要一个（假设有足够的选择性）。尝试减少选择列表中的列，如果“足够”，请将这些列添加到索引included columns（这可以消除对聚簇索引的书签查找并提高性能）。
您可以将数据分成不同的表（例如按日期范围），然后通过视图进行组合。
它也非常依赖于您的硬件（＃核心，RAM，I / O子系统速度，网络带宽）
建议您发布表和索引定义。
答案 1 :(得分：1)
首先总是避免使用Select *因为这将导致select获取所有列，如果只有一个索引只需要你需要的列，那么你将获取大量不必要的数据。仅使用您需要检索的确切列，可以让服务器更好地使用索引。
其次，查看索引的包含列，这样可以将经常请求的数据包含在索引中，以避免必须获取行。
第三，您可能会尝试使用int列作为日期并将日期转换为int。 Ints在范围搜索中通常比日期更有效，特别是如果您有时间信息，并且如果您可以跳过时间信息，则索引会更小。
要检查的另一件事是服务器使用的执行计划，如果在菜单中启用show execution plan，您可以在管理工作室中看到这一点。它可以指出问题所在，您可以看到它尝试使用哪些索引，有时它会建议添加新索引。
它还可以指示其他问题，表扫描或索引扫描很糟糕，因为它表明它必须在索引搜索良好时扫描整个表或索引。
了解服务器的工作原理是一个很好的资源。
答案 2 :(得分：0)
如果您在日期添加索引，由于索引搜索+键查找而不是聚簇索引扫描，您可能会加快查询速度，但如果日期过滤器返回太多记录，索引将无法帮助您完全因为为索引搜索的每个结果执行了键查找。然后，SQL服务器将切换到聚簇索引扫描。
要获得创建覆盖索引所需的最佳性能，即在索引的“包含列”部分中包含您需要的所有列，但如果您使用select *
select *方法的另一个问题是您无法以有效的方式使用缓存或执行计划。如果您确实需要所有列，请确保指定所有列而不是*。
您还应该完全确定对象名称，以确保您的计划可以重复使用
答案 3 :(得分：0)
您可以考虑创建一个存档数据库，然后将10到20年后的任何内容移动到存档数据库中。这应该会大大加快您的主要生产数据库，但会保留所有历史数据以满足报告需求。
答案 4 :(得分：0)
我们在谈论什么类型的查询？
这是生产表吗？如果是的话，请进一步规范化，看看你是否能够进一步规范数据库。
如果这是针对报告的，包括大量的Ad Hoc报告查询，则会尖叫数据仓库。
我会创建一个带有单独预处理报告的DW，其中包括您可以预期的所有计算和聚合。
我有点担心商业模式涉及处理大数据，但没有产生足够的收入，甚至没有吸引足够的风险投资来升级到企业。