我来帮你梳理下这个权限配置的痛点——你遇到的情况其实挺典型的：db_datareader+public角色权限不够，但给sysadmin又太不安全。咱们一步步拆解原因和解决方案：

为什么db_datareader权限不够？ #

大概率是服务器级别的基础权限缺失，或者你的程序悄悄访问了系统对象（比如系统视图）。db_datareader只是数据库级的读取权限，但要连接到SQL Server本身，还需要服务器级的CONNECT SQL权限；另外如果程序里用到了系统目录视图（比如sys.tables、sys.columns），db_datareader是没有这些权限的。

正确的最小权限配置步骤 #

1. 服务器级别权限（必须） #

确保你的执行账号（不管是SQL登录还是Windows账号）拥有CONNECT SQL权限：

-- 如果是SQL登录账号
GRANT CONNECT SQL TO [YourSQLLogin];

-- 如果是Windows账号
GRANT CONNECT SQL TO [DOMAIN\YourWindowsAccount];

（注：新建的登录账号默认会继承public服务器角色，而public默认有CONNECT SQL权限，但如果权限被修改过，就需要显式授予）

2. 数据库级别权限（核心） #

将账号映射到目标数据库后，配置以下权限：

• 保留public角色（所有数据库用户默认必须属于这个角色）
• 添加db_datareader角色：这个角色允许读取数据库中所有用户表的数据，足够满足大多数只读场景

如果还是报错，检查你的C#程序是否访问了系统对象（比如查询系统视图），如果是，需要单独授予对应系统对象的SELECT权限，比如：

-- 示例：授予读取系统列信息的权限
GRANT SELECT ON sys.columns TO [YourDatabaseUser];

如何仅授予单表访问权限？ #

当然可以！如果你不想让账号读取整个数据库的表，只需要针对目标表配置权限：

1. 不要给账号添加db_datareader角色
2. 直接授予目标表的SELECT权限：

GRANT SELECT ON [dbo].[YourTargetTableName] TO [YourDatabaseUser];

3. 确保数据库级别有CONNECT权限（public角色默认包含这个，一般不需要额外配置，如果没有的话执行：GRANT CONNECT ON DATABASE::[YourDatabaseName] TO [YourDatabaseUser];）

额外排查点 #

• 确认Windows任务计划的运行账号和你配置权限的账号一致：很多时候调试用自己的账号，任务计划用服务账号，容易出现权限配置错对象的情况
• 检查C#连接字符串的身份验证方式：如果是Windows身份验证，确保任务计划账号已在SQL Server中创建对应的Windows登录；如果是SQL身份验证，确保连接字符串里的用户名/密码对应你配置权限的SQL登录

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