看起来你遇到的是典型的登录名与数据库用户混淆导致的登录失败，结合你的操作步骤，我帮你梳理下排查和修复的方法：

核心问题：登录时用错了身份标识 #

你创建的readonlylogin是服务器级的登录名（LOGIN），而readonlyuser是数据库级的用户（USER）——Azure SQL登录时必须使用登录名，而不是数据库用户名。你现在用readonlyuser作为登录账号，自然会提示登录失败。

修复步骤1：使用正确的登录名尝试登录 #

直接用readonlylogin作为用户名，密码保持1231!#ASDF!a重新尝试登录，这应该能解决最基础的登录问题。

额外排查点（如果登录还是失败） #

如果用readonlylogin还是登不上，检查以下几个配置：

• 确认Azure SQL服务器开启了SQL身份验证
  在Azure门户的SQL服务器页面，进入「设置 > 服务器管理员」，确认是否勾选了「SQL身份验证」。如果只开启了Azure AD身份验证，SQL登录名是无法使用的。

• 确认登录名拥有CONNECT SQL权限
  默认创建LOGIN时会自动赋予CONNECT SQL权限，但如果之前有修改过服务器角色，可能会丢失这个权限。可以用pt_admin登录master数据库，执行以下命令检查并修复：

  -- 检查权限
  SELECT name, permission_name 
  FROM sys.server_permissions sp
  JOIN sys.server_principals spri ON sp.grantee_principal_id = spri.principal_id
  WHERE spri.name = 'readonlylogin';
  
  -- 如果没有CONNECT SQL，手动添加
  GRANT CONNECT SQL TO readonlylogin;
  

• 确认数据库用户与登录名的映射正确
  虽然你已经执行了创建用户的命令，但可以在DB1和DB2中执行以下命令验证映射关系：

  SELECT name, login_name 
  FROM sys.database_principals 
  WHERE name = 'readonlyuser';
  

  确保login_name显示为readonlylogin，如果不是，重新执行创建用户的命令：

  DROP USER IF EXISTS readonlyuser;
  CREATE USER readonlyuser FROM LOGIN readonlylogin;
  EXEC sp_addrolemember 'db_datareader', 'readonlyuser';
  

验证只读权限 #

登录成功后，你可以在DB1/DB2中执行以下命令验证权限：

-- 尝试读取数据（应该成功）
SELECT * FROM [你的表名];

-- 尝试修改数据（应该失败，提示权限不足）
UPDATE [你的表名] SET [列名] = 'test' WHERE 1=1;

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