关于Always Encrypted的查询阻塞、对象锁定及加密时表访问的咨询

先给你明确的结论，再展开细节：

加密/密钥轮换期间的读取权限 #

• 完全可以正常读取或查询目标表！
  你查到的「写入操作被阻塞」是准确的，但读取操作不受影响——SQL Server在后台执行数据重加密时，会通过快照隔离或类似机制保证读可用性，只要你的客户端有正确的列主密钥访问权限，就能正常查询已加密的列数据。

关于查询阻塞与对象锁定 #

• 加密过程中确实会涉及锁，但并非全程阻塞：
  • 操作开始和结束阶段，目标表会被加上Sch-M（架构修改）锁，这个锁会阻塞所有针对该表的读写操作，但持续时间通常很短。
  • 中间的实际数据重加密阶段，SQL Server会使用更温和的锁（比如Sch-S共享架构锁或行级锁），只会阻塞写入，不会影响读取。
• 你遇到的小表加密耗时极长，很大概率是因为大量依赖对象（视图、存储过程、触发器、索引等）的存在：SQL Server需要逐一校验这些对象是否与加密列兼容（比如是否有直接引用加密列的计算逻辑、非对称索引等），这个校验过程会大幅拉长整体操作时间，甚至可能因为依赖对象的锁竞争间接导致阻塞变长。

额外建议 #

• 如果要优化加密速度，建议先清理不必要的依赖对象，或者在业务低峰期执行操作，减少并发写入的冲突。
• 对于列加密密钥轮换，确实需要提前规划：因为轮换过程和初始加密的锁机制一致，同样会阻塞写入，所以尽量选择业务流量最低的窗口执行，避免影响正常业务。

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