Sql 表别名如何影响性能？

在阅读有关调优SQL查询的内容时，我在某个地方读到“当您使用多个表时，请始终使用表别名并在所有列名前面加上别名。”

---

表别名如何影响性能？或者它们真的会影响吗？

几乎没有影响，性能影响可以忽略不计，但您将有更好的时间阅读查询。这只是为了你的方便

---

性能影响是在SQL Server程序本身中分配几kb的内存来存储别名等。与执行查询所需的其他操作相比，这几乎算不上什么。

别名根本不会以任何实际或可测量的方式影响性能（编辑时添加斜体）。也就是说，它会给查询编译增加一个几乎无法测量的延迟（如果有的话）。一旦编译（并重新使用），它就没有任何效果

当您有多个表时，别名会消除歧义，因为您知道它来自哪个表。它还可以防止将来的表更改破坏查询。比方说，您将一个审核列添加到一个表中，而该列已经存在于另一个表中。使用这两个表而没有别名的查询将中断

---

别名在某些情况下也是必需的，例如绑定到架构的视图

---

SQL解析引擎（在执行查询之前读取所有查询，并在将来使用这些信息缓存已编译的查询以便更快地执行）是唯一查看别名的工具，并使用它来帮助消除符号查找中的歧义。在执行存储之前对其进行解析时，系统已经生成了符号，就像任何其他语言中的任何其他可编译语句一样。

我有使用别名的经验。与不使用别名相比，查询所需的时间要多得多

我对PostgreSQL有过这样的经历，我的问题如下

不带别名

select applicant.application_id, form_data, application_defect.defect_id from applicant INNER JOIN audit_trail on applicant.email = audit_trail.email inner join application_defect on applicant.application_id = application_defect.application_id where application_defect.defect_id like '1%' and form_data like '%FaceApi%' ;  

select ap.application_id, au.form_data, ad.defect_id from applicant ap INNER JOIN audit_trail au on ap.email = au.email inner join application_defect ad on ap.application_id = ap.application_id where ad.defect_id like '1%' and form_data like '%FaceApi%' ;

使用别名

select applicant.application_id, form_data, application_defect.defect_id from applicant INNER JOIN audit_trail on applicant.email = audit_trail.email inner join application_defect on applicant.application_id = application_defect.application_id where application_defect.defect_id like '1%' and form_data like '%FaceApi%' ;  

select ap.application_id, au.form_data, ad.defect_id from applicant ap INNER JOIN audit_trail au on ap.email = au.email inner join application_defect ad on ap.application_id = ap.application_id where ad.defect_id like '1%' and form_data like '%FaceApi%' ;

---

如果您使用的是SQL Server，您可以在此处找到更多信息：。就我个人而言，我从未听说过别名有助于提高性能。可读性和对数据的良好理解（反映在如何编写查询以及使用什么连接、过滤器）对我来说更为重要。。。有证据吗？我发布的链接上的一个答案提到这是SQL Server 2000中的一个问题。但是，我从未见过它，查询执行计划中肯定没有提到它；-）而且，与诸如表格扫描之类的成本相比，它可能不值得考虑。也许这是过去糟糕的日子里的一个问题？性能影响是在SQL Server程序本身中分配几kb的内存来存储别名等。就像我说的，微不足道。迂腐，但是。。。解析可能会受到不可忽略的影响。例如，Oracle试图通过将sql语句的前n个字符散列为索引保存到sql语句缓存中来保存硬解析步骤。长度超过n个字符的语句可能散列到同一个bucket，从而导致额外的检查以验证命中。短别名可以压缩语句，并提供更好的机会获得唯一的命中率。此外，在不使用列别名的情况下，解析器必须找出该列属于哪个表。但这根本不值得考虑。可读性更为重要。“在某些情况下，别名也是必需的，例如绑定到架构的视图。”-您能举个例子吗