刚碰到过几乎一模一样的问题，给你梳理几个一步步排查的方向，大概率能找到根源：

1. 先查生产环境的连接字符串 #

这是最容易踩的坑！本地调试用的连接字符串可能没问题，但发布到Azure应用服务后，配置里的连接字符串很可能藏着问题：

• 登录Azure门户，找到你的应用服务 → 配置 → 连接字符串，检查有没有不小心加上ApplicationIntent=ReadOnly参数（复制粘贴的时候很容易带进来），这个参数会强制只读连接。
• 确认连接字符串里的身份信息：如果用SQL认证，用户名密码是不是对应有读写权限的账号；如果用托管身份，有没有正确配置（后面会讲）。

2. 检查数据库用户的权限 #

本地你可能用的是服务器管理员账号（权限拉满），但生产环境的应用账号大概率是受限的：

• 打开Azure SQL数据库的查询编辑器，用管理员账号登录后，执行以下命令查看用户权限：

  EXEC sp_helprotect @username = '你的应用使用的数据库用户名'
  

• 确认该用户至少拥有db_datareader + db_datawriter角色权限（遵循最小权限原则，别直接给db_owner），如果只有db_datareader，那肯定只能读不能写。添加权限的命令：

  ALTER ROLE db_datawriter ADD MEMBER '你的应用用户名';
  ALTER ROLE db_datareader ADD MEMBER '你的应用用户名';
  

3. 确认数据库本身的状态 #

有时候数据库会被意外设置为只读模式（比如备份、维护操作后没改回来）：

• 在查询编辑器里执行：

  SELECT DATABASEPROPERTYEX('你的数据库名', 'Updateability') AS UpdateStatus;
  

• 如果返回READ_ONLY，赶紧改成读写模式：在Azure SQL数据库门户 → 设置 → 配置，找到“数据库状态”，改成Read/write。

4. 托管身份权限排查（如果用了Managed Identity） #

如果你的应用是用托管身份连接Azure SQL，那得确保身份有数据库读写权限：

1. 先确认Azure SQL服务器已经设置了Azure AD管理员（门户 → Azure Active Directory → 管理员）。
2. 在查询编辑器里执行：

   -- 创建对应应用服务的AD用户
   CREATE USER [你的应用服务名称] FROM EXTERNAL PROVIDER;
   -- 添加读写权限
   ALTER ROLE db_datawriter ADD MEMBER [你的应用服务名称];
   ALTER ROLE db_datareader ADD MEMBER [你的应用服务名称];
   

5. 深挖500错误的具体原因 #

光看500没用，得抓详细异常日志：

• 登录应用服务门户 → 监控 → 日志流，实时查看应用运行时的错误信息，通常会抛出具体的异常，比如“权限不足”“无法打开登录所请求的数据库”“事务死锁”等。
• 如果日志流不够详细，开启诊断设置，把应用日志存储到Blob存储或者Log Analytics，然后查看完整的堆栈信息，这是定位问题的关键。

6. 排查资源限制与锁问题 #

• 检查Azure SQL的资源使用率：门户 → 监控 → 查看DTU/CPU/写入延迟指标，如果DTU长期接近100%，会导致写入操作被限流，这时候需要升级服务层级（比如从Basic升到Standard）。
• 排查事务锁：执行以下命令查看有没有长期持有的锁，导致写入阻塞：

  SELECT 
      request_session_id AS SessionID,
      resource_type AS ResourceType,
      request_mode AS LockMode,
      request_status AS LockStatus
  FROM sys.dm_tran_locks 
  WHERE resource_database_id = DB_ID('你的数据库名');
  

按照这个顺序排查，基本能解决90%以上的只读问题，我之前就是连接字符串里不小心带了ApplicationIntent=ReadOnly，折腾了半天😂。

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