为何内存优化表插入耗时比临时表高2-4秒

• 持久化配置差异
  默认创建的内存优化表为持久化表（durability 为 SCHEMA_AND_DATA），所有插入操作都会写入事务日志保证宕机可恢复，日志写入开销远高于临时表。会话级临时表（# 前缀）仅存储在 tempdb 中，日志记录仅用于事务回滚，实例重启后数据自动丢失，日志开销被极度压缩。如果你的内存优化表未显式设置 DURABILITY = SCHEMA_ONLY，仅这一项就会带来几秒钟的额外开销。
• 索引维护额外开销
  内存优化表的哈希索引、非聚集索引都需要在插入时同步维护，哈希索引需要计算哈希值、处理哈希冲突，范围索引需要更新内存中的B树结构。而临时表如果未手动创建索引，插入时无需额外维护索引结构，即使创建了索引，传统引擎的临时表索引维护逻辑也比内存优化引擎更轻量化。
• 内存优化引擎的固定开销
  内存优化表插入需要执行乐观并发控制校验、行版本元数据生成、内存页分配校验等固定逻辑，哪怕是单会话无并发的插入场景，这部分逻辑也会执行。而临时表属于会话私有资源，不会涉及并发冲突校验，插入逻辑走的是传统引擎的简化路径，固定开销极低。
• 测试场景不匹配内存优化表的优势区间
  内存优化表的性能优势体现在高并发写入、低锁冲突的场景，单会话低并发批量插入场景下，内存优化表的固定开销占比极高，反而会比临时表更慢。如果你使用的是逐行循环插入而非批量插入语法，这种性能差距会进一步拉大。
• 缓冲区清空操作的不对称影响
  你每次测试前清空的缓冲区默认是用户数据库的缓存，而临时表存储在tempdb中，tempdb的缓存通常不会被常规的缓冲区清空命令清理，临时表的写入可以复用tempdb中已缓存的页，进一步降低了写入开销，相当于测试条件本身就对临时表更有利。

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