MySQL 和 PHP：执行两个后续查询的 PHP 代码块的原子性和可重入性 - 有多危险？

Question

在 MySQL 中，我必须检查 select 查询是否返回任何记录，如果没有，我插入一条记录。但我担心 PHP 脚本中的整个 if-else 操作并不像我希望的那样原子，即在某些情况下会中断，例如，如果在需要处理相同记录的情况下调用脚本的另一个实例：

if(select returns at least one record)
{
    update record;
}
else
{
    insert record;
}

我这里没有使用事务，并且自动提交已打开。我正在使用 MySQL 5.1 和 PHP 5.3。该表是InnoDB。我想知道上面的代码是否不是最优的并且确实会崩溃。我的意思是两个实例重新输入相同的脚本，并发生以下查询序列：

1. 实例 1 尝试选择记录，未找到任何记录，进入插入查询块
2. 实例 2 尝试选择记录，未找到任何记录，进入该块对于插入查询，
3. 实例 1 尝试插入记录，成功，
4. 实例 2 尝试插入记录，失败，自动中止脚本

这意味着实例 2 将中止并返回错误，跳过插入查询语句后面的任何内容。我可以使错误不致命，但我不喜欢忽略错误，我更想知道我的恐惧是否真实存在。

更新：我最终做了什么（这样可以吗？）

相关表有助于限制（实际上是允许/拒绝）应用程序发送给每个收件人的消息量。系统不应在 Z 周期内向接收者 Y 发送多于 X 条消息。该表[概念上]如下：

create table throttle
(
    recipient_id integer unsigned unique not null,
    send_count integer unsigned not null default 1,
    period_ts timestamp default current_timestamp,
    primary key (recipient_id)
) engine=InnoDB;

[稍微简化/概念上的] PHP 代码块应该执行原子事务，以维护表中的正确数据，并根据节流状态允许/拒绝发送消息：

function send_message_throttled($recipient_id) /// The 'Y' variable
{
    query('begin');

    query("select send_count, unix_timestamp(period_ts) from throttle where recipient_id = $recipient_id for update");

    $r = query_result_row();

    if($r)
    {
        if(time() >= $r[1] + 60 * 60 * 24) /// The numeric offset is the length of the period, the 'Z' variable
        {/// new period
            query("update throttle set send_count = 1, period_ts = current_timestamp where recipient_id = $recipient_id");
        }
        else
        {
            if($r[0] < 5) /// Amount of messages allowed per period, the 'X' variable
            {
                query("update throttle set send_count = send_count + 1 where recipient_id = $recipient_id");
            }
            else
            {
                trigger_error('Will not send message, throttled down.', E_USER_WARNING);
                query('rollback');
                return 1;
            }
        }
    }
    else
    {
        query("insert into throttle(recipient_id) values($recipient_id)");
    }

    if(failed(send_message($recipient_id)))
    {
        query('rollback');
        return 2;
    }

    query('commit');
}

好吧，忽略 InnoDB 死锁发生的事实，这很好不是吗？我并不是在拍胸脯或做任何事情，但这只是我能做的性能/稳定性的最佳组合，缺少使用 MyISAM 并锁定整个表，我不想这样做，因为与更新/插入相比，我不想这样做选择。

Answer 1

看起来您已经知道问题的答案以及如何解决您的问题。这是一个真正的问题，您可以使用以下方法之一来解决它：

• SELECT ... FOR UPDATE
• INSERT ... ON DUPLICATE KEY UPDATE
• 事务（不要使用 MyIsam）
• 表锁

Answer 2

这种情况可能和可能发生取决于此页面的执行频率。

安全的选择是使用交易。您写的同样的事情仍然会发生，除了您可以安全地检查事务内的错误（如果插入涉及多个查询，并且只有最后一个插入中断），允许您回滚该错误变得无效。

所以（伪）：

#start transaction
if (select returns at least one record)
{
    update record;
}
else
{
    insert record;
}

if (no constraint errors)
{
    commit; //ends transaction
}
else
{
    rollback; //ends transaction
}

您也可以锁定表，但根据您正在执行的工作，您必须获得整个表的独占锁（您不能SELECT ... FOR UPDATE 不存在的行，抱歉）但这也会阻止从表中读取数据，直到完成为止。