2

这可能是一个奇怪的问题，但不知道如何研究它。执行以下查询时：

  SELECT Foo.col1, Foo.col2, Foo.col3
  FROM Foo
  INNER JOIN Bar ON Foo.ID = Bar.BID

我倾向于使用TableName.Column而不仅仅是col1, col2, col3

有性能差异吗？为每列指定表名是否更快？

我的猜测是，是的，它更快，因为查找列名并区分它需要一些时间。

如果有人知道我可以阅读此内容的链接，我将不胜感激。我什至不知道如何更好地为这个问题命名，因为不知道如何搜索它。

4

2 回答 2

5

首先：这应该没关系。查找列的时间在典型查询的总处理时间中只占很小的一部分，因此这可能是寻找额外性能的错误地点。

第二：Tablename.Colname 比唯一更快Colname，因为它消除了搜索引用表（以及类似表的结构，如视图和子查询）以查找合适列的需要。同样：差异在于统计噪声内部。

第三：使用Tablename.Colname 是一个好主意，但出于其他原因：如果您Colname只使用，并且查询中的一个表获得一个具有相同名称的新列，那么您最终会得到一个众所周知的“模糊列”名称”错误。这种列的典型候选者通常是“comment”、“lastchanged”和friends。如果你限定你的 col 引用，这个可维护性问题就会消失 - 你的查询将照常工作，忽略新字段。

于 2013-05-13T23:17:31.610 回答
4

如果它更快，则差异肯定可以忽略不计，例如每个查询几微秒。查询中提到的有关表的所有数据都必须加载到内存中，因此它不会保存任何磁盘访问。它是在查询解析期间完成的，而不是在数据处理期间完成的。即使您运行查询数千次，它也可能无法弥补输入这些额外字符所花费的时间，当然也不能弥补我们讨论它所花费的时间。:)

但这会使查询时间更长，因此花费在通信上的时间会稍微多一些。如果您通过网络发送查询，则可能会否定解析期间节省的任何时间。不过，您可以通过使用短表别名来减少这种情况：

SELECT t.col1, t.col2
FROM ReallyLongTableName t

作为一般规则，当担心数据库性能时，您只需要关注时间取决于表中行数的方面。无论数据量如何，任何相同的东西都会陷入困境，除非您正在处理非常小的表（在这种情况下，您为什么要打扰数据库 - 使用平面文件）。

于 2013-05-13T23:19:10.907 回答