如何避免批量导入大数据时的LCK_M_SCH_S锁等待问题？

嘿，针对你遇到的批量导入锁表导致只读查询卡LCK_M_SCH_S等待的问题，结合你的场景（只读操作允许脏读、数据无需完全准确），我给你整理了几个实操性很强的方案，分三类拆解：

这是从根源解决问题的思路，毕竟锁持有时间越短，影响越小：

• 拆大批次为小批量导入：别一次性导入200万行，拆成每批1万-5万行（具体数量根据你的数据库性能调整），每导入一批就提交一次事务。比如把原来的单条INSERT INTO target_table SELECT * FROM source_table改成循环分批插入，每批提交。这样不仅锁的持有时间会大幅缩短，像InnoDB、SQL Server这类支持行级锁的数据库，还能避免锁升级成表级锁。
• 用低影响的批量导入语法：如果是SQL Server，用BULK INSERT或者bcp工具时，加上TABLOCK和ROWS_PER_BATCH参数，会触发批量更新锁（而非排他表锁），只读查询更容易绕过；MySQL的话，用INSERT ... SELECT时可以加LOW_PRIORITY，让导入操作让步给读请求。
• 分区切换（适合超大数据量）：如果你的数据库支持分区（比如SQL Server、MySQL、PostgreSQL），可以把目标表分成多个分区。导入时先把数据写到临时分区，等导入完成后，瞬间把临时分区切换到主表中——这个切换操作几乎是原子性的，不会锁主表。整个导入过程中，主表的查询完全不受影响，完美解决锁表问题。

既然你的只读操作允许脏读，那直接调整查询的事务隔离级别就能快速解决等待问题：

• 设置读未提交隔离级别：在每个只读查询开始前，执行对应的隔离级别设置语句：
  • SQL Server：SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
  • MySQL：SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
    这样查询会直接读取未提交的导入数据，不会等待表锁，完全跳过LCK_M_SCH_S等待。缺点是可能读到导入过程中的中间脏数据，但你已经明确允许这种情况，所以完全适用。
• 用快照隔离（更优雅的替代方案）：如果你的数据库支持快照隔离（比如SQL Server、PostgreSQL），可以开启数据库的快照隔离功能，然后查询时设置：
  • SQL Server：SET TRANSACTION ISOLATION LEVEL SNAPSHOT;
  • PostgreSQL：SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;（PostgreSQL的快照隔离逻辑类似可重复读）
    这样查询会读取导入开始前的一致性快照数据，不会等待锁，而且不会读到中间脏数据，只是数据是导入前的状态，也符合你“无需完全准确”的需求。

如果不想调整隔离级别或导入逻辑，也可以主动检测表锁，返回备用数据：

• 数据库层面检测锁：通过查询数据库的系统视图判断目标表是否被锁，比如SQL Server可以查sys.dm_tran_locks，MySQL查performance_schema.data_locks。举个SQL Server的例子：

IF EXISTS (
    SELECT 1 
    FROM sys.dm_tran_locks l
    JOIN sys.tables t ON l.resource_associated_entity_id = t.object_id
    WHERE t.name = 'your_target_table'
      AND l.request_mode IN ('X', 'Sch-M') -- 排他锁或架构修改锁
)
BEGIN
    -- 返回替代结果，比如缓存的历史数据
    SELECT * FROM your_cache_table;
END
ELSE
BEGIN
    -- 正常查询目标表
    SELECT * FROM your_target_table;
END

• 应用层超时降级：在应用代码里给查询设置超时时间，如果超时就自动切换到备用数据（比如缓存的历史数据、默认值）。比如Java JDBC设置setQueryTimeout(5)，Python用psycopg2的connect参数设置connect_timeout，超时后返回替代结果。

优先推荐导入端分批+查询端读未提交/快照隔离的组合，这几乎能彻底解决你的问题，而且对业务影响最小。如果必须保留原导入逻辑，那查询端调整隔离级别是最快的解决方案。

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