哪个更快：数据库级别或应用程序级别的字符串连接？答案

【问题标题】：Which is faster: string concatenation on the database level, or the application level?哪个更快：数据库级别或应用程序级别的字符串连接？
【发布时间】：2012-03-06 16:42:38
【问题描述】：

我在 DQL 中有一个选择 3 列的简单查询：

        $qb->select("c.zip_code, c.name, s.state")
           ->where("c.zip_code LIKE :input");

我想要的输出是

"[c.zip_code], [c.name], [s.state]"

目前，我在 PHP 级别连接字符串以获得所需的字符串。

使用CONCAT() 函数在数据库级别执行此操作是否更快？

【问题讨论】：

有没有写一个有意义的基准直接比较？

标签： php mysql string concatenation

【解决方案1】：

这并不是优化的相关点。你应该注意哪个更易读/更实用，我个人会在 PHP 级别上做。

【讨论】：

+1。它可能与真正大量的请求相关，在这种情况下缓存连接的结果 (memcached) 会提高速度。
“为了清楚起见”+1，但这是总是使用 PHP。我发现有些表达式的 SQL 更容易。

【解决方案2】：

这种逻辑属于应用程序的显示层，而不是数据库。

【讨论】：

太笼统了。现在数据库已经抽象得太多了，任何一层都没有本质上的问题。

【解决方案3】：

我想用mysql级别为什么我们必须处理这种操作，其中 mysql 为此提供了内置函数我的意见 MYSQL 两者可能需要相同的时间

【讨论】：

【解决方案4】：

我会让数据库完成繁重的工作并连接数据，虽然这对小型应用程序可能意义不大，但对于大型应用程序，您的应用程序脚本可能会开始达到内存阈值。
如果您需要在不同的地方显示相同的数据会发生什么情况，您是复制并粘贴代码还是使用相同的查询？

归根结底，现在的性能可能是一样的，但后来的代码重用、易于更改等问题变得更加重要。

【讨论】：

【解决方案5】：

给定两个大致相等的选择，我相信你在这种情况下会有这样的选择，我将使用 风险因素 做出最终决定。

如果我以后需要在应用程序中拆分列，那么在数据库加入列之后拆分应用程序中的列，即使不是不可能，成本也会很高。因此，将它们加入应用程序的风险较小，因为我拥有以任何一种方式呈现它们所需的数据。

另外，我觉得扩展应用程序层比扩展数据库层更容易。您只需添加应用程序服务器。数据库瓶颈比应用程序瓶颈更难处理。

【讨论】：

【解决方案6】：

您可以比 MySql 服务器更轻松地横向扩展 PHP 服务器。例如，在 AWS 上，您可以创建自动缩放条件来向上/向下扩展您的 PHP 服务器实例。

【讨论】：