php - mysql select语句中的算术-内存大小错误

Question

当我在最后一个选择中添加算术时，收到此查询的以下错误消息...这是一个非常简单的计算，因此不确定问题是什么:

alert.last_email is a utc timestamp (unsigned integer)
alerts.email_rate is value in minutes (unsigned integer)

这是一个消息队列...我试图将 sends_in 设为发送消息的秒值。

例如，使用正常时间而不是时间戳...最后一封电子邮件在晚上 7:00 发送，速率为 15 分钟，因此将在 7:15 发送。如果当前时间是 7:10，则发送时间为 5 分钟或300 秒。

Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 505364672 bytes) in Unknown on line 0

$stmt = $db->prepare("
    SELECT
        users.username AS username,
        computers.computer_name AS computer_name,
        alerts.last_email AS last_email,
        alerts_queue.alert_id AS alert_id,
        alerts_queue.event_title AS event_title,
        alerts_queue.event_target AS event_target,
        alerts_queue.capture_timestamp AS capture_timestamp,
        alerts.last_email + (alerts.email_rate * 60) - UNIX_TIMESTAMP() AS sends_in
    FROM computers
    INNER JOIN users
        ON users.computer_id = computers.computer_id
    INNER JOIN alerts
        ON alerts.user_id = users.user_id
    INNER JOIN alerts_queue
        ON alerts_queue.user_id = alerts.user_id
    WHERE computers.account_id = :cw_account_id AND computers.status = :cw_status
");

$binding = array(
    'cw_account_id' => $_SESSION['user']['account_id'],
    'cw_status' => 1
);
$stmt->execute($binding);

$results = $stmt->fetchAll(PDO::FETCH_ASSOC);

更新:

计算未按预期进行:

TIMESTAMPDIFF(SECOND, UTC_TIMESTAMP(), FROM_UNIXTIME(UNIX_TIMESTAMP() + alerts.email_rate * 60)) AS sends_in

以此作为测试...差异应该是 900 秒，但它返回 -13500。

TIMESTAMPDIFF(SECOND, UTC_TIMESTAMP(), FROM_UNIXTIME(UNIX_TIMESTAMP() + 15 * 60)) AS sends_in

更新:

我的错误 - 这返回正确的值:

TIMESTAMPDIFF(SECOND, NOW(), FROM_UNIXTIME(UNIX_TIMESTAMP() + 15 * 60)) AS sends_in

工作解决方案:

看起来有点草率，但是确实有效。 TIMESTAMPDIFF 使用当前时区...我的 last_email 值是一个 unix 时间戳，这就是 FROM_UNIXTIME 发挥作用的地方。由于 last_email 是无符号整数，因此除非将其转换为有符号整数，否则算术将无法正常工作。我总是将时间戳设置为无符号的原因是因为永远不会有负数，但在使用 MySQL 进行算术的情况下，这会导致问题。

TIMESTAMPDIFF(SECOND, NOW(), FROM_UNIXTIME(CONVERT(alerts.last_email,SIGNED) + alerts.email_rate * 60)) AS sends_in

Answer 1

这似乎是 PHP 错误，而不是 MySQL 错误。我怀疑这个错误是在调用fetchAll函数时发生的；导致错误的是数组 $results 的分配。 (我只是猜测。)根据错误消息，尝试分配近 482 MB 的内存，但 PHP 限制为 32 MB。

(我认为 PHP 中有一个设置设置了这个限制，但我不认为你真的想要去那里......因为似乎没有任何理由需要分配那么多内存。

部分问题在于 fetchAll，同时将结果集中的每一行检索到内存中。

但是，如果仅当您在 SELECT 列表中添加最后一个表达式时才会发生这种情况，我怀疑 PDO 为最后一个表达式的结果保留了过多的内存量。例如，MySQL 报告元数据中存在奇怪的数据类型和/或 PDO 未检测到该表达式返回的正确数据类型，并且正在使用一些巨大的分配来存储它。

<小时/>

要对此进行调试，请尝试更改该查询以返回文字整数值来代替最后一个表达式，即替换此:

alerts.last_email + (alerts.email_rate * 60) - UNIX_TIMESTAMP() AS sends_in

这样:

42 AS sends_in 

看看 PHP 是否发出同样的错误消息。如果不是，我怀疑 PDO 没有将您的原始表达式视为简单的整数类型。下一步是将该表达式的结果转换或转换为整数数据类型... CONVERT(expr,UNSIGNED) 或 CONVERT(expr,SIGNED)

也就是说，将最后一个表达式替换为:

CONVERT(alerts.last_email + (alerts.email_rate * 60) - UNIX_TIMESTAMP(),SIGNED) 
  AS sends_in

尝试一下，看看会产生多大的烟球。

就实际的 MySQL 语句而言，我认为尝试减去无符号整数可能会引发错误。 (我认为 SQL_MODE 中有一些东西可以控制这种行为，并且我认为该行为取决于 MySQL 版本。)可能需要将无符号整数转换/转换为有符号(64 位)整数，像这样的丑陋的东西可能工作:

CONVERT(CONVERT(alerts.last_email,SIGNED) + (CONVERT(alerts.email_rate,SIGNED) * 60) 
  - CONVERT(UNIX_TIMESTAMP(),SIGNED),SIGNED)
  AS sends_in

就我个人而言，我更愿意避免使用日期时间和时间戳值进行无符号整数数学运算，并使用 MySQL 日期时间函数。

<小时/>

我不确定我是否回答了您的问题。我什至不确定你问了一个问题。