我有两张桌子
表A （主键是ID） id \ firstname \ lastname \ zip \ state
表B some_field \ business name \ zip \ id
我需要使用表B 中的ID获取与ID相关联的名字和姓氏（请注意，这与表A 中的ID相同）< / p>
我在表A和表B上做了一个JOIN，这样我就可以获得名字和姓氏
我的一位朋友说我不应该以这种方式使用JOIN，而且我应该完成两个单独的查询。这有什么意义吗？
JOIN是否会执行使进程比两个单独查询慢的任何操作？两个单独的查询怎么能比一个查询更快？
答案 0 :(得分：3)
问：JOIN是否会做任何使这个过程比两个单独的查询慢的事情？
答：是的，有些事情可以使联接变慢，所以我们无法排除这种可能性。我们无法做出一揽子声明，即两个单独的查询会更快并且＃34;或者说＃＆＃34;加入会更慢＆＃34;正确索引的两个表的等值连接可能更有效。但是，通过实际执行报表，预期的数据生产量以及观察和衡量绩效，可以最好地衡量绩效。
一些可能使连接变得更慢的事情......复杂的连接谓词（涉及包含在函数中的列，不等式比较，复合谓词与OR结合，涉及多个表，其中优化器具有更多连接路径考虑提出执行计划的操作。或者，生成一个hugh jass中间结果的连接稍后使用GROUP BY折叠。（简而言之，可以写一个使用连接操作的非常低效的语句但通常不的连接操作是罪魁祸首。这些事情只是一个抽样，它不是一个详尽的清单。）
JOIN是您描述的用例的规范模式。不清楚为什么你的朋友建议你避免JOIN操作。你的朋友给出了什么理由。
如果您的主查询主要针对（不幸名为）Table_B，并且您想要从Table_A查找first_name和last_name，则JOIN适合于此。
如果您只从Table_B返回一行（或几行），则另一个查询获得first_name和last_name的额外往返不会成为问题。但是如果从Table_B返回数千个行，那么对Table_A执行数千个单独的单例查询将会破坏性能和可伸缩性。
如果您的朋友担心Table_B中的外键列中的值与id的{{1}}列中的值不匹配，或者存在NULL在外键列中的值，您的朋友会指出内部联接会阻止返回Table_A行。
在这种情况下，我们使用外部连接，因此即使未找到Table_B中的匹配行，我们也可以从Table_B返回该行
您的朋友可能也会担心JOIN操作的性能，可能是因为您的朋友因未定义合适的索引而被烧毁。
假设Table_A上存在合适的索引（带有前导列Table_A）。并且id id中的Table_A是唯一的...然后在单列外键和单列主键之间使用简单的等值连接执行单个查询可能更多比运行大量单独的语句更有效率。
或许，您的朋友可能会关注一个不成熟的ORM框架的问题，该框架不能有效地处理从连接查询返回的结果。
如果数据库的实现方式是两个表可以位于不同的数据库服务器上，那么使用JOIN将面对该设计。如果这是设计意图，表格的分离，那么应用程序也应该为两个表中的每一个使用单独的连接。
除非你的朋友可以提供一些避免JOIN操作的具体原因，否则我建议你忽略他的建议。
（必须有充分的理由避免JOIN操作。我怀疑你的朋友可能并不了解关系数据库是如何工作的。）
答案 1 :(得分：0)
在你的情况下，它没有任何重大区别，因为你只有一个id作为外键，无论如何都有一个索引。由于它是索引的，因此效率很高，并且连接就是最好的。
根据你想要的东西，你想要完成的领域和想要完成的事情等，它会变得更加复杂。
所以，是的，你的情况没有太大区别。