MySQL存储过程中能否手动设置受影响行数？

针对你用MySql.Data .NET客户端以非查询方式执行存储过程时，日志记录导致返回受影响行数不准确的问题，这里提供无需修改应用代码的纯存储过程解决方案：

核心思路 #

问题根源是ExecuteNonQuery会返回存储过程中最后一条DML语句的受影响行数，日志插入操作会覆盖原增删改的行数统计。我们需要在日志记录完成后，执行一条受影响行数等于原增删改操作行数的DML语句，让ExecuteNonQuery最终返回正确数值。

可行方案：临时表批量生成+删除 #

通过递归CTE快速生成对应行数的临时表数据，再删除这些数据，让最后一步DELETE的受影响行数等于原增删改操作的行数。

示例存储过程代码 #

DELIMITER //
CREATE PROCEDURE UpdateUserStatus(IN user_id INT, IN new_status INT)
BEGIN
    DECLARE affected_rows INT;
    DECLARE original_affected INT;

    -- 执行目标增删改操作
    UPDATE users 
    SET status = new_status 
    WHERE id = user_id;
    SET affected_rows = ROW_COUNT();
    SET original_affected = affected_rows;

    -- 执行日志记录（可根据业务需求判断是否记录0影响行数的操作）
    IF affected_rows > 0 THEN
        -- 假设LogOperation是你的日志存储过程
        CALL LogOperation('UPDATE', 'users', user_id, affected_rows);
    END IF;

    -- 关键操作：让最后一条DML返回原增删改的行数
    IF original_affected > 0 THEN
        -- 创建会话级临时表，连接断开后自动销毁
        CREATE TEMPORARY TABLE IF NOT EXISTS temp_dummy (id INT);
        
        -- 用递归CTE生成对应行数的数据集
        WITH RECURSIVE row_generator AS (
            SELECT 1 AS num
            UNION ALL
            SELECT num + 1 FROM row_generator WHERE num < original_affected
        )
        INSERT INTO temp_dummy SELECT num FROM row_generator;
        
        -- 删除临时表数据，此操作的受影响行数等于原增删改行数
        DELETE FROM temp_dummy;
    END IF;
END //
DELIMITER ;

细节说明 #

1. 临时表特性：临时表是会话级的，不同客户端连接的临时表相互独立，不会产生数据冲突，且连接关闭后自动销毁，无需手动清理。
2. 递归CTE限制：MySQL默认递归CTE的最大深度是1000，如果需要处理超过1000行的受影响行数，可在存储过程开头添加：SET SESSION cte_max_recursion_depth = 10000;（数值根据业务调整）。
3. 0行数场景处理：如果原增删改操作影响行数为0，可选择不记录日志，此时最后一条语句就是原增删改操作，ExecuteNonQuery自然返回0，无需额外处理。

内容的提问来源于stack exchange，提问作者Dewey Vozel