Mysql 选择TableName.Col1与选择Col1

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

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

我倾向于使用

TableName.Column

而不仅仅是

col1、col2、col3

性能有什么不同吗？为每列指定表名是否更快

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

---

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

首先：这不重要。查找列的时间只占典型查询总处理时间的很小一部分，因此这可能是寻找额外性能的错误点

其次：

Tablename.Colname

比

Colname

更快，因为它不需要在引用的表（以及类似表的结构，如视图和子查询）中搜索拟合列。再次说明：差异存在于统计噪声中

---

第三：使用

Tablename.Colname

是一个好主意，但由于其他原因：如果您仅使用

Colname

，并且查询中的一个表获得了一个同名的新列，那么您最终会出现众所周知的“不明确列名”错误。此类专栏的典型候选人通常是“评论”、“最后更改”和“朋友”。如果您限定col引用，这个可维护性问题就会消失——您的查询将一直工作，忽略新字段。

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

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

SELECT t.col1, t.col2
FROM ReallyLongTableName t

---

一般来说，在担心数据库性能时，您只需要关心时间取决于表中行数大小的方面。无论数据量多大，任何相同的东西都会陷入混乱，除非您处理的是非常小的表（在这种情况下，您为什么要处理数据库--使用平面文件）。

谢谢您的解释。即使在性能上略有不同，我还是感觉好多了，因为我确实花时间写表名（有时是短名），而不仅仅是列名。谢谢你的回答。有道理。它只是困扰着我，我不知道这是肯定的：）+1，我忘了这方面。不过，我确实相信，只要我们不打破MTU边界，这应该是可以忽略的，特别是在所有使用中断合并的现代NIC中。这一切都可以忽略不计，我们只是在争论它有多么可以忽略不计。：）