我必须在我的 SQL Server 数据库中处理具有数百万行的集合。
几乎我所有的命令都使用该MERGE语句。我在这里和那里合并，这张桌子和那张桌子。我为此使用存储过程，因为我相信这将提供最佳性能。
我发现这个过程对我来说太慢了（合并 2kk 行 - 似乎从 5 到 50 秒随机），也就是说，性能并不是最好的，由于某种原因我找不到原因：我打开了任务管理器和资源监视器，启动了一些繁重的MERGE查询，确保实际执行计划中不存在扫描或其他不愉快的项目。而且我看到 CPU、内存和磁盘驱动器的消耗非常低。我仍然不知道其原因。
最近我还发现内存优化表与本机存储过程相结合应该提供更好的性能。
事实证明，Merge它不适用于 MO 表，并且 MO 表不适用于本机存储过程。
在 MSDN 上替换 Merge的唯一示例使用奇怪的方法，基于 while 循环和额外的列 RowId 来“按索引访问行”。好吧，我学到了更多信息，我重复了 MSDN 示例，在该列上建立了一些带有大量存储桶 (8kk) 的哈希索引，并且确实有一些性能提升。
但同样，循环中的每次迭代都需要至少两次索引查找，以及满足条件时的插入/更新/删除。
所以我问：有没有什么有用的策略来放置一个真正的高性能merge？有没有办法，我不知道，可能是写一个 CLR 程序？那会更好吗？还有其他提示或提示吗？