问：这有意义吗？
A：不，没有正当理由，这是没有意义的。
问：JOIN 是否会导致进程比两个单独的查询慢？
A：是的，有些事情会使连接变慢，所以我们不能排除这种可能性。我们不能笼统地说“两个单独的查询会更快”或“连接会更慢”。
正确索引的两个表的等值连接可能更有效。但是，最好通过实际执行语句、以预期的数据生产量以及观察和测量性能来衡量性能。
一些可能使连接变慢的事情...复杂的连接谓词（涉及包含在函数中的列、不等式比较、与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 中的外键列中的值与Table_A 中的id 列中的值不匹配，或者外键列中有 NULL 值，您的朋友指出内部连接会阻止来自Table_B 的行被返回是正确的。
在这种情况下，我们将使用 outer 连接，因此即使未找到来自 Table_A 的匹配行，我们也可以返回来自 Table_B 的行。
您的朋友可能还担心 JOIN 操作的性能，可能是因为您的朋友因未定义合适的索引而被烧毁。
假设在Table_A 上存在合适的索引（带有前导列id）。并且id 在Table_A 中是唯一的...那么在单列外键和单列主键之间进行简单等值连接的单个查询的性能可能比运行大量单独的语句。
或者，也许您的朋友担心 ORM 框架不成熟，它不能有效地处理连接查询返回的结果。
如果数据库的实现方式是两个表可以位于不同的数据库服务器上，那么使用 JOIN 将与该设计相悖。如果这是设计意图，即表的分离，那么应用程序也应该为两个表中的每一个使用单独的连接。
除非您的朋友可以提供避免 JOIN 操作的特定原因，否则我的建议是您忽略他的建议。
（必须有充分的理由避免 JOIN 操作。我怀疑您的朋友可能不了解关系数据库的工作原理。）