嘿，这个问题我之前帮同行处理过类似的，咱们直接说结论：你的思路完全可行！新建数据库+用SAS密钥/托管身份配置存储访问，再迁移外部表定义，就能实现不让用户碰底层Blob、只让他们查询数据的目标，而且完全不用动原D365 Synapse Link创建的数据库。

下面给你拆解具体的操作步骤和注意事项：

一、核心实现逻辑 #

本质是用一个“中间数据库”来承接存储访问的身份（SAS/托管身份），把用户的查询请求和底层存储的权限彻底隔离开：用户只需要有中间数据库的查询权限，而存储访问的身份是你预先配置好的独立身份，和用户自身权限无关。

二、具体操作步骤 #

1. 新建无服务器SQL池数据库，配置存储访问身份 #

• 直接在Synapse Studio里新建一个无服务器SQL池数据库，创建的时候重点配置外部数据源的认证方式：
  • 用SAS密钥：创建外部数据源时指定CREDENTIAL = SAS_CREDENTIAL_NAME，这个SAS密钥你提前生成好，要包含Blob存储的读取和列出权限（因为Delta Lake需要读取_delta_log目录的元数据）。
  • 用托管身份：给Synapse工作区的托管身份（或者你新建的用户托管身份）分配Blob存储的存储Blob数据读取者角色，然后创建外部数据源时用这个身份做认证。
• 这个步骤里，所有的存储访问权限都绑定在你配置的SAS/托管身份上，和用户无关。

2. 迁移原外部表的定义到新数据库 #

• 先从原D365 Synapse Link创建的数据库里导出外部表的脚本：
  你可以在Synapse Studio里找到原表，右键选择“生成CREATE脚本”；或者用T-SQL查询系统视图获取定义，比如：

  SELECT OBJECT_DEFINITION(OBJECT_ID(N'原数据库名.dbo.原表名')) AS CreateTableScript
  

• 修改导出的脚本：把脚本里的外部数据源替换成你刚在新数据库里创建的、用SAS/托管身份的数据源，保留原表的LOCATION路径完全不变（就是指向Delta Lake存储的那个路径）。
• 在新数据库里执行修改后的脚本，就能得到和原表结构、数据指向完全一致的外部表了。

3. 给用户授权新数据库的查询权限 #

• 只需要给用户授予新数据库的SELECT权限就行，比如执行：

  GRANT SELECT ON DATABASE::[你的新数据库名] TO [目标用户名/角色]
  

• 这一步不需要给用户任何底层Blob存储的角色权限，因为访问存储的身份是你配置的SAS/托管身份，不是用户自己的。

三、关键注意事项 #

• SAS密钥的配置细节：生成SAS时要确保勾选读取和列出权限，设置合理的过期时间，避免后续失效。如果担心过期，可以定期更新SAS密钥并同步到外部数据源的凭证里。
• 数据同步的一致性：因为新外部表和原表指向的是同一个Delta Lake存储路径，D365 Synapse Link的实时/增量同步数据会自动同步到新表，不需要额外维护。
• 原数据库完全不受影响：你完全不用修改或删除原D365 Synapse Link创建的数据库，它该怎么同步数据就怎么同步，新数据库只是做了一个“权限隔离的镜像查询层”。

如果操作过程中遇到脚本修改的小问题，比如原表的外部数据源引用，随时调整就行，这个方案已经被很多人验证过了，完全适配你的场景！