插入1000万条数据耗时超30分钟，sys.schema_index_statistics指标异常咨询

核心问题分析 #

你插入1000万条数据时，其中一个外键的rows_selected高达37亿+，但被引用表仅21000条数据且有主键索引，这种异常通常是每次外键检查都触发了全表扫描，而非高效的索引查找，累计下来就会产生天文数字般的扫描行数。

可能的原因 #

• 单条循环插入+索引失效：如果存储过程是用循环逐行插入，而非批量插入，那1000万次插入就会触发1000万次外键检查。若检查时没用到被引用表的主键索引（比如数据类型不匹配、隐式转换），每次都要全表扫描21000条数据，1000万*21000=210亿，和你看到的37亿量级匹配（可能包含另一个外键的扫描）。
• 统计信息过时：被引用表的统计信息很久没更新，数据库优化器误以为表数据量很大或数据分布异常，导致选择了全表扫描而非索引查找的执行计划。
• 数据类型/排序规则不匹配：目标表外键列与被引用表主键列的数据类型、长度、collation不一致，触发隐式类型转换，导致主键索引无法被利用。比如外键是varchar(10)，主键是int，数据库会把主键转换成字符串再匹配，索引直接失效。
• 额外约束/触发器干扰：目标表或被引用表存在触发器、嵌套查询的CHECK约束等，在插入时触发了额外的扫描操作，导致rows_selected被额外累积。

解决办法 #

• 改成批量插入：将单条循环插入改为INSERT ... SELECT或批量提交（比如每次插入1000-10000条），数据库会对批量插入的外键检查做优化，大幅减少检查次数。
• 验证数据类型一致性：对比目标表外键列和被引用表主键列的所有属性，确保数据类型、长度、排序规则完全一致，消除隐式转换。
• 更新统计信息：对被引用表执行更新统计信息的命令，比如SQL Server中：

  UPDATE STATISTICS 被引用表名;
  

  让优化器获取最新的表数据分布，选择正确的索引查找计划。
• 查看实际执行计划：捕获插入语句的执行计划，确认外键检查步骤是否走了主键索引。如果是全表扫描，针对性修复（比如修正数据类型、更新统计信息）。
• 临时禁用外键（谨慎）：如果已提前确认所有插入数据的外键合法性，可以临时禁用外键约束，插入完成后再启用。比如SQL Server中：

  -- 禁用外键
  ALTER TABLE 目标表名 NOCHECK CONSTRAINT 外键约束名;
  -- 执行插入操作
  -- 启用外键并检查现有数据
  ALTER TABLE 目标表名 CHECK CONSTRAINT 外键约束名;
  

  注意：禁用期间可能插入非法数据，必须确保数据已验证。

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