c# - 为什么给定代码使用 Azure SQL 生成 'The request limit for the database is X'

Question

所以我有代码在 Azure Functons 消费计划中运行。我的数据库限制为 60 个并发登录或生成此错误的内容:

The request limit for the database is X

我的问题是，为什么交易中的这个循环会达到这个限制？一次交易是一次请求？或不？我知道代码质量很差，但这只是因为我在搜索过程中使用了硬核解决方案。

SOME_QUERY1 = "INSERT INTO SomeTable (p1,p2,p3,p4) Values (p1,p2,p3,p4); SELECT CAST(SCOPE_IDENTITY() as int)";
SOME_QUERY2 = "INSERT INTO OtherTable (10 fields)"; 

public async Task<IEnumerable<string>> SaveBusinessTransaction(TransactionBatchEntity businessEntity)
{
    using (var connection = new SqlConnection(_connectionString))
    {
        connection.Open();
        var successfullyAddedTransactions = new List<string>();

        using (var transaction = connection.BeginTransaction())
        {
            try
            {
                var transactionId = (await connection.QueryAsync<int>(SOME_QUERY1, new { Paramter = 1 }, transaction)).Single();

                foreach (var details in businessEntity.Details)
                {
                    var detailsEntity = new
                    {
                        //some fields
                    };

                    await connection.ExecuteAsync(SOME_QUERY2, detailsEntity, transaction);
                    successfullyAddedTransactions.Add(detailsEntity.TransactionNumber);
                }

                transaction.Commit();

                return successfullyAddedTransactions;
            }
            catch (Exception)
            {
                transaction.Rollback();
                connection.Close();
                throw;
            }
        }
    }
}

编辑:

执行上下文的重要缺失部分

transactions.ForEach(t => _sqlService.SaveBusinessTransaction(t));

Answer 1

检查 this ，它可以帮助你。这是最近的，这是他们那边的一个错误。

"Looks like there was an issue on the back end regarding the HADR TRANSPORT service not being up for about two hours.Apparently, the SQL service was restarted and the HADR TRANSPORT service did not start as expected."

或this .

"Sql server sometime uses more than one worker thread to execute a query so the number of connections doesn't always correspond to the number of execution threads."

"Since Azure SQL doesn't support setting this parameter globally, our solution was to add OPTION (MAXDOP 1) to the offending query so its execution would be more predictable (at the cost of parallelism and speed)."