在 MySQL 与 PHP 中进行计算答案

【问题标题】：Doing calculations in MySQL vs PHP在 MySQL 与 PHP 中进行计算
【发布时间】：2023-03-09 09:35:01
【问题描述】：

上下文：

我们有一个 PHP/MySQL 应用程序。
某些计算部分直接在 SQL 中完成。例如：过去 24 小时内创建的所有用户都将通过 SQL 查询返回（NOW() – 1 天）

一位开发人员和我之间正在进行一场辩论，我认为我们应该：

A.将所有计算/代码/逻辑保存在 PHP 中，并将 MySQL 视为“愚蠢”的信息存储库

他的意见：

B.根据更容易/更快的情况进行混合和匹配。 http://www.onextrapixel.com/2010/06/23/mysql-has-functions-part-5-php-vs-mysql-performance/

我正在研究可维护性的观点。他关注的是速度（正如文章所指出的，MySQL 中的某些操作更快）。

@bob-the-destroyer @tekretic @OMG 小马 @mu 太短了 @都铎君士坦丁 @tandu @哈雷

我同意（而且很明显）高效的 WHERE 子句属于 SQL 级别。但是，像这样的例子呢：

在 SQL 中使用 NOW() - 1 天计算 24 周期以选择过去 24 小时内创建的所有用户？
返回所有用户的大写名字和姓氏？
连接字符串？
（想法，伙计们？）

属于 SQL 域的清晰示例：

特定的 WHERE 选择
嵌套 SQL 语句
排序/排序
选择 DISTINCT 项
计算行数/项目数

【问题讨论】：

哪个选项可以更好地扩展？是让数据库返回信息更好，还是在给我之前坐下来计算？
如果问题集中在可维护性上，那么它在很大程度上取决于技能领域。是Mysql还是PHP他的强项？给自己怎么样？一个复杂的查询可能会节省 20 行 PHP 代码，但它对不理解其结果的 PHP 编码人员无济于事。

标签： php mysql performance maintainability

【解决方案1】：

我会发挥每个系统的优势。

聚合、连接和过滤逻辑显然属于数据层。它更快，不仅因为大多数数据库引擎为此进行了 10 多年的优化，而且您可以最大限度地减少在数据库和 Web 服务器之间转移的数据。

另一方面，我使用的大多数数据库平台在处理单个值方面的功能都很差。日期格式和字符串操作之类的东西在 SQL 中很糟糕，你最好在 PHP 中完成这项工作。

基本上，将每个系统用于其构建目的。

在可维护性方面，只要清楚地划分发生在哪里发生的事情，将这些划分为逻辑类型应该不会造成太大问题，当然也不足以抵消好处。在我看来，代码的清晰性和可维护性更多的是关于一致性，而不是将所有逻辑放在一个地方。

Re: 具体例子...

我知道这也不是您所指的，但日期几乎是一种特殊情况。您要确保系统生成的所有日期都是在 Web 服务器或数据库上创建的。如果数据库服务器和网络服务器曾经配置为不同的时区（我已经看到这种情况发生），否则这样做会导致一些潜在的错误。例如，假设您有一个createdDate 列，默认值为getDate()，该列在由数据库 插入时应用。如果您要插入一条记录，则使用 PHP 中 生成的日期（例如date("Y-m-d", time() - 3600)，选择最近一小时内创建的记录，您可能不会得到您期望的结果。至于您应该在哪一层这样做，我更喜欢 DB，因为在示例中，它允许您使用列默认值。
对于大多数应用程序，我会在 PHP 中执行此操作。结合名字和姓氏听起来很简单，直到你意识到有时你也需要称呼、头衔和中间名缩写。另外，您几乎肯定会遇到这样的情况：您想要用户的名字、姓氏以及称呼+名字+姓氏的组合。将它们连接到数据库端意味着您最终会移动更多数据，尽管实际上，它非常小。
视情况而定。如上所述，如果您想单独使用它们，最好在性能方面将它们单独拉出并在需要时连接起来。也就是说，除非您处理的数据集很大，否则可能还有其他因素（如您提到的可维护性）具有更大的影响。

一些经验法则：

应在数据库中生成增量 ID。
就我个人而言，我喜欢 DB 应用的默认设置。
选择时，任何减少记录数量的事情都应由 DB 完成。
做一些事情来减小数据集 DB 端的大小通常是件好事（例如上面的字符串示例）。
正如你所说；排序、聚合、子查询、连接等应始终在数据库端。
此外，我们还没有讨论过它们，但触发器通常是不好的/必要的。

您在这里面临一些核心权衡，而平衡实际上取决于您的应用程序。

有些事情绝对应该——每次——总是在 SQL 中完成。排除大量 SQL 任务的一些例外情况（如日期的事情）可能非常笨拙，并且可能会让您在逻辑上陷入困境。在您的代码库中搜索对特定列（例如）的引用时，很很容易错过视图或存储过程中包含的那些。

性能始终是一个考虑因素，但取决于您的应用程序和具体示例，可能不是一个重要因素。您对可维护性的担忧可能非常有效，并且我提到的一些性能优势非常轻微，因此请注意过早的优化。

此外，如果其他系统直接访问数据库（例如，用于报告或导入/导出），您将从数据库中的更多逻辑中受益。例如，如果您想直接从另一个数据源导入用户，则可以在 SQL 中实现诸如电子邮件验证功能之类的可重用功能。

简短回答：视情况而定。 :)

【讨论】：

Oracle 和 MySQL 的日期格式非常适合 - 对于原生 TSQL 中的 SQL Server 来说，这不能说是这样。
是的，查看文档，MySQL 日期格式与 PHP 大致相当，Oracle 没有那么多但仍然可以。我最熟悉的 MSSQL 没有用于输出任意日期格式的内置函数。
SQL Server 让您可以使用CAST 或CONVERT，它们只提供预先确定的字符串——远低于 MySQL 的 DATEFORMAT 或 Oracle 的 TO_CHAR 的能力。
"选择时，任何减少记录数的事情都应该由数据库来完成。"这仅仅是因为它意味着更早地减少数据集的大小，还是因为它发生在数据库中，所以这条规则还有其他一些优势？
@WAF 数据库是唯一可以访问索引的地方。根据物理模式，很容易出现这样的情况，即选择全部并过滤客户端不仅会给网络和客户端带来更多负载，而且还会在数据库服务器上增加负载，从表中读取数千个块而不是三个或四个来自索引，然后一个来自表。

【解决方案2】：

我不喜欢重新发明轮子。我也喜欢使用最好的工具来完成需要完成的任务，所以：

当我可以直接从 DB 获取结果集而无需进一步处理时，我会这样做 - 你的情况是一个简单的查询，带有一个简单的 WHERE 子句。想象一下，当您有 1000 万用户并让他们使用 PHP 时会发生什么，只需要其中的 100 个 - 您猜对了 - 您的 Web 服务器很可能崩溃
再次，当您需要从 2 个或更多表中获取数据时，MySQL 比 PHP 好很多
当您需要计算记录时 - 数据库非常擅长
我倾向于支持 FK 约束的应用程序级处理
此外，我倾向于避免使用存储过程，更愿意在应用程序级别实现该业务逻辑（当然，除非我们谈论的是庞大的数据集）。

最后，我想说你的同事在所提出的案例中是对的

【讨论】：

我不知道轮船是发明出来的。
但现在我的玩笑没有意义了:(

【解决方案3】：

如果您将一半的逻辑放在数据库中，另一半放在 php 中，那么在接下来的 6 个月内，当您进行更改时，您将花费两倍的时间来弄清楚发生了什么。

话虽如此，您的数据库查询应该有足够的逻辑，以便它们为您的 php 提供所需的准确数据。如果您发现自己在 php 代码中循环了数千条 mysql 记录，那么您做错了什么。但是，在规模的另一端，如果您在 mysql 查询中运行 if / else 语句，那么您也做错了（可能只需要重写您的查询）。

我会避开存储过程。虽然理论上它们是一个很棒的概念，但您通常可以在 php 中以更快的开发时间完成相同的结果，并且您还可以知道所有逻辑在哪里。

【讨论】：

PHP 中的存储过程和 SQL 代码对于简单的单个语句是相同的。一旦您处理多个语句，PHP 中的 SQL 就会丢失，因为您无法弥补 PHP 和数据库之间的往返行程。其次，在您的代码库中保持一致将减少混乱。

【解决方案4】：

随着结果集的增加，MySQL 将更好地扩展。坦率地说，将数据库视为“哑数据”存储库是一种资源浪费......

可维护性往往会受到熟悉程度的影响。如果您不熟悉 PHP，那么它不会是您最初选择的可维护性 - 是吗？

【讨论】：

我承认我曾经属于“愚蠢的数据存储库”阵营，但这主要是由于缺乏 SQL 经验和大量使用 Sybase 的糟糕经验。从那以后，我知道了我的方法的错误，现在我倾向于将我的计算推向尽可能接近数据（因此尽可能深入数据库）。
我不完全确定你的第一句话是什么意思。您是说将这些计算放在 MySQL 中会随着系统的额外负载而更好地扩展？
@ErickRobertson 的评论，尽管这已经晚了两年。是的，将其推送到数据库会更快，因为将结果从数据库传输到 PHP 的开销更少，通过减少内存分配时间（如果数据库是远程的，那么网络时间）。小数据集（Kb 范围）的好处很小，但对于 500,000 行 (5Mb+)，差异很明显。

【解决方案5】：

在 SQL 中获取数据所花费的时间非常耗时，但是一旦完成，计算就会变得更多。获取数据后，无论哪种方式都不会耗费太多时间，但在 SQL 中巧妙地处理可以为大型数据集提供更好的结果。

如果您从 MYSQL 获取数据，然后在 PHP 中对获取的数据进行计算，那么获取所需结果并避免 PHP 处理要好得多，因为这会增加更多时间。

一些基本点：

MYSQL 中的日期格式非常强大，大多数格式在 Mysql 中都可用。如果您有非常具体的日期格式，那么您可以使用 PHP。
字符串操作在 SQL 中很糟糕，最好在 PHP 中完成。如果你不需要做大的字符串操作，那么你可以在 Mysql SELECTs 中进行。
选择时，任何减少记录数的操作都应由 SQL 而不是 PHP 完成
排序数据应始终在 Mysql 中完成
应该始终在 Mysql 中进行聚合，因为数据库引擎是专门为此设计的。
子查询和连接应始终在数据库端。它将减少您的大量 PHP 代码。当您需要一次从 2 个或更多表中获取数据时，SQL 比 PHP 好得多
要统计记录，SQL很棒。

【讨论】：

【解决方案6】：

回答如下：

在 SQL 中使用 NOW() - 1 天计算 24 周期以选择过去 24 小时内创建的所有用户？
使用 PHP 创建日期并使用 WHERE 子句查找数据。日期操作在 PHP 中实现起来要快得多。
返回所有用户的大写名字和姓氏？
选择数据库中的所有用户，然后使用 PHP 将字符串大写。再次，它在 PHP 中实现要快得多。
连接一个字符串？
再次，PHP 用于字符串操作。

（想法，伙计们？）

使用 PHP 进行所有数据操作，因为它更容易实现。更清楚地说，在 PHP 中操作一个简单的$variable 比在 SQL 中写出整个字符串操作更容易。在 PHP 中操作，然后在 SQL 中更新数据库。

属于 SQL 域的清晰示例：

具体的 WHERE 选择 - 是的。

嵌套 SQL 语句 - 我会重新评估你的 PHP 数据处理，但如果你必须，好吧。

排序/排序 - 排序肯定是 SQL 语句的工作，但您应该只在 SELECT 语句上进行排序。任何其他排序，例如排序和更新数据库，都应该由 PHP 排序，因为再次操作 $vars 比写出 UPDATE SQL 语句更容易。

选择 DISTINCT 项目 - 是的。

计数行/项目 - 在 PHP 中使用：$Number_Of_Results = count($Results);。

【讨论】：