删除 – >数据库引擎从相关数据页和输入行的所有索引页中查找并删除该行.因此,索引越多,删除所用的时间越长.
TRUNCATE – >简单地删除所有表格的数据页面,使其成为删除表格内容的更有效选项.
假设以上是正确的(如果没有,请纠正我)：
>不同的恢复模式如何影响每个语句？如果有任何影响
>删除时,是扫描所有索引还是仅扫描行？我会假设所有索引都被扫描(并没有被搜索？)
>如何复制命令？是否在每个订户上发送和处理sql命令？或者MSsql比那更智能？
解决方法
DELETE -> the database engine finds and removes the row from the
relevant data pages and all index pages where the row is entered.
Thus,the more indexes the longer the delete takes.
是的,虽然这里有两种选择.可以由执行基表删除的同一运算符逐行从非聚簇索引中删除行.这称为窄(或每行)更新计划：
或者,非聚集索引删除可以由单独的运算符执行,每个非聚簇索引一个.在这种情况下(称为宽或每索引更新计划),完整的操作集存储在工作表(急切的假脱机)中,然后每个索引重放一次,通常按特定的非聚集索引的键显式排序,以鼓励顺序访问模式.
TRUNCATE -> simply removes all the table’s data pages en masse making
this a more efficient option for deleting the contents of a table.
是.由于多种原因,TRUNCATE TABLE效率更高：
>可能需要更少的锁.截断通常只需要在表级别进行单个模式修改锁定(并且每个extent解除分配时使用独占锁定).删除可能会获得较低(行或页面)粒度的锁定以及取消分配的任何页面上的独占锁定.
>只有截断才能保证从堆表中释放所有页面.即使指定了排它表锁提示,删除也可能会在堆中留下空页(例如,如果为数据库启用了行版本控制隔离级别).
>截断是always minimally logged(无论使用何种恢复模型).只有页面解除分配操作记录在事务日志中.
>如果对象的大小为128或更大,截断可以使用deferred drop.延迟丢弃意味着实际的解除分配工作由后台服务器线程异步执行.
How do different recovery modes affect each statement? Is there is any
effect at all?
删除始终完全记录(删除的每一行都记录在事务日志中).如果恢复模型不是FULL,则日志记录的内容会有一些小的差异,但这仍然是技术上的完整日志记录.
When deleting,are all indexes scanned or only those where the row is?
I would assume all indexes are scanned (and not seeked?)
删除索引中的行(使用前面显示的窄更新计划或宽更新计划)始终是按键访问(搜索).扫描删除的每一行的整个索引将是非常低效的.让我们再看一下前面显示的每个索引更新计划：
执行计划是需求驱动的管道：父运算符(左侧)通过一次请求一行来驱动子运算符执行工作. Sort运算符是阻塞的(它们必须在生成第一个排序行之前使用它们的整个输入),但它们仍然由它们的父(Index Delete)驱动,请求第一行. Index Delete从完成的Sort中一次拉一行,更新每行的目标非聚集索引.
在广泛的更新计划中,您经常会看到基表更新运算符将行添加到行流中.在这种情况下,“聚簇索引删除”会将非聚簇索引键列添加到流中.存储引擎需要此数据来定位要从非聚集索引中删除的行：
How are the commands replicated? Is the sql command sent and processed
on each subscriber? Or is sql Server a bit more intelligent than that?
在使用事务或合并复制发布的表上,截断是not allowed.如何复制删除取决于复制的类型及其配置方式.例如,快照复制只是使用批量方法复制表的时间点视图 – 不跟踪或应用增量更改.事务复制的工作原理是读取日志记录并生成适当的事务以在订阅者处应用更改.合并复制使用触发器和元数据表跟踪更改.
