Sql 什么时候查询太大？

我在监控电话并将其输入数据库。我把呼叫者、被叫者、开始者、结束者放入数据库。平均每天有70-80个电话，周末没有，因此每周有350-400个。该程序将使用很长一段时间，因此一年后数据库中将有许多项

程序的一部分以图表的形式显示通话量/天，并在列表框中显示谁拨打了谁的电话。为此，我使用一个典型的select*from表来检索信息

查询何时会如此之大，以至于用户将体验性能损失

更新：

我需要表格中的所有信息，所以根据一些人的说法，选择*是最好的选择

---

数据库中的每一行都包含1个int和4个字符串，即简单数据。

您没有指定数据存储是什么、模式、索引等，因此可以继续的信息非常少

但是，通常情况下，我们都会开玩笑地说：

当用户开始抱怨时

---

一根绳子有多长

这取决于许多因素，包括您认为的“性能损失”，因此无法给出确切的答案。你必须自己测试一下，看看现在对它进行限制

你真的需要所有时间的数据吗？对于图表/列表，什么是合理的？30天？60天？用户可选择

尽管如此，每年2万个电话并不是一个巨大的数据量

---

另外，选择表单不好*-您应该始终指定您正在选择的列列表。

如果您只做一个简单的选择，那么在有人注意到之前，我猜有数百万条记录

当然，如果您的db服务器在一台速度较慢的机器上，这也会妨碍它

你在做Where子句或分组吗？有人加入吗？如果是的话，它们是否在索引列上

---

最好的答案是：视情况而定。

在应用程序的生命周期内，即使您的容量增加，也不应该出现性能问题。只要：

您对查询使用的字段有很好的了解。 在你的询问中，你不会做一些非常愚蠢的事情。 如果没有好的索引，最终会出现问题。一些不太重要的建议：

指定所需的列，而不是使用“选择”* 确保您正在报告的查询没有每秒被调用一千次或类似的疯狂行为。

---

嗯，这可能有点晚了@罗伯特：如果没有OP提供更多信息，任何真正的答案都为时过早：用几年的记录加载数据库，看看——这真的是了解瓶颈所在的唯一方法。Redgate有一些工具来帮助加载数据。