T-SQL中TaskNotes表随机插入失败问题求助及解决方案咨询

这种随机的部分插入失败确实挺头疼的，我之前处理过类似的生产问题，结合你的场景，咱们一步步拆解可能的原因和对应的解决办法：

1. 事务未正确包裹（最常见的元凶） #

你现在在C#里先后调用两个存储过程，如果这两个操作没有放在同一个数据库事务里，就会出现"Records插入成功，但AddTaskNotes因为突发异常（比如网络波动、临时锁等待超时）失败，却无法回滚Records"的情况。这也是随机失败的典型特征之一。

解决办法：
在C#代码中用事务把两个存储过程的调用绑定在一起，确保要么全成功，要么全回滚。示例代码大概是这样：

using (var conn = new SqlConnection("你的数据库连接字符串"))
{
    conn.Open();
    // 开启事务
    using (var tran = conn.BeginTransaction())
    {
        try
        {
            // 调用AddRecord获取生成的InputID
            var cmdAddRecord = new SqlCommand("Time.AddRecord", conn, tran);
            cmdAddRecord.CommandType = CommandType.StoredProcedure;
            // 绑定参数：TeamID、UserID等
            cmdAddRecord.Parameters.Add("@TeamID", SqlDbType.Int).Value = teamId;
            cmdAddRecord.Parameters.Add("@UserID", SqlDbType.Int).Value = userId;
            cmdAddRecord.Parameters.Add("@TimeIN", SqlDbType.DateTime).Value = timeIn;
            cmdAddRecord.Parameters.Add("@TimeOUT", SqlDbType.DateTime).Value = timeOut;
            
            var inputId = (int)cmdAddRecord.ExecuteScalar();

            // 调用AddTaskNotes插入备注
            var cmdAddNotes = new SqlCommand("Time.AddTaskNotes", conn, tran);
            cmdAddNotes.CommandType = CommandType.StoredProcedure;
            cmdAddNotes.Parameters.Add("@InputID", SqlDbType.Int).Value = inputId;
            cmdAddNotes.Parameters.Add("@TaskNotes", SqlDbType.NVarChar, -1).Value = taskNotes;
            
            cmdAddNotes.ExecuteNonQuery();

            // 提交事务
            tran.Commit();
        }
        catch (SqlException ex)
        {
            // 回滚事务，记录详细错误日志（错误码、消息、InputID等）
            tran.Rollback();
            Logger.Error($"插入记录及备注失败，InputID（如果生成）: {inputId}，SQL错误码: {ex.Number}，消息: {ex.Message}", ex);
        }
        catch (Exception ex)
        {
            tran.Rollback();
            Logger.Error($"插入记录及备注失败，InputID（如果生成）: {inputId}", ex);
        }
    }
}

2. TaskNotes表的锁阻塞/超时 #

你怀疑锁的问题是有道理的。如果TaskNotes表存在长时间运行的查询、批量更新，或者其他事务持有锁未释放，就会导致你的插入请求被阻塞，超过默认超时时间后失败。

解决办法：

• 给TaskNotes表加索引：针对InputID字段创建非聚集索引，能减少锁的范围，降低阻塞概率：

CREATE NONCLUSTERED INDEX IX_TaskNotes_InputID ON Time.TaskNotes(InputID);

• 排查阻塞源头：用SQL Server的sp_who2命令，或者Extended Events/Profiler捕捉失败时刻的阻塞进程，看是哪个操作在占用TaskNotes的锁，针对性优化。
• 调整命令超时：在C#调用时，把SqlCommand.CommandTimeout设为更大的值（比如300秒，默认是30），不过这只是缓解，核心还是要解决阻塞根源。

3. 参数传递或存储过程定义的隐性问题 #

你的AddTaskNotes存储过程看起来没问题，但有可能存在数据类型不匹配的情况：比如Records的主键是INT，但AddTaskNotes的@InputID参数定义成了BIGINT，或者C#里传递参数时用了AddWithValue导致类型推断错误，最终插入失败。

解决办法：

• 确保存储过程参数和主键类型完全一致：比如Records的Input ID是INT，那AddTaskNotes的参数也要定义为INT：

CREATE PROCEDURE Time.AddTaskNotes
    @InputID INT,
    @TaskNotes NVARCHAR(MAX)
AS
BEGIN
    SET NOCOUNT ON;
    INSERT INTO Time.TaskNotes (InputID, TaskNotes) VALUES (@InputID, @TaskNotes);
END

• 在C#里明确指定参数类型，避免用AddWithValue：

cmdAddNotes.Parameters.Add("@InputID", SqlDbType.Int).Value = inputId;

4. 未被捕获的异常 #

有可能C#代码里调用AddTaskNotes时发生了异常，但被吞掉了（比如try-catch块没覆盖到，或者catch里没记录日志），导致你不知道失败的具体原因。

解决办法：
一定要把所有数据库操作的异常详细记录下来，包括SQL错误码、错误消息、涉及的InputID等，这样才能精准定位问题。比如上面代码里的日志记录逻辑，能帮你快速区分是锁超时（错误码1205）、参数错误还是其他问题。

5. 单个存储过程的优化（如果想回退到原方案） #

如果之前单个存储过程也有问题，可能是SCOPE_IDENTITY()的可靠性问题（比如Records表有触发器插入其他表时，SCOPE_IDENTITY()可能返回触发器生成的ID）。可以改用OUTPUT子句来获取主键，更可靠：

INSERT INTO Time.Records (TeamID, UserID, TimeIN, TimeOUT)
OUTPUT inserted.InputID
VALUES (@TeamID, @UserID, @TimeIN, @TimeOUT);

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