insertintotablename与Select*intotablename比较

insertintotablename时表tablename必须存在
Select*intotablename时表不能存在

在的故障还原模型为“简单”的时候，Select*intotablename要快，因为在数据库的故障还原模型为“简单”的时候Select*intotablename是不会产生大量日志的

--测试：
--前提条件是数据库的故障还原模型为“简单”

--1、用Selectinto生成大数据量的表 你可以在语句运行之前查看你的ldf文件（log）
--然后在运行之后再查看，log增长很小，而建表的速度比较快
ifexists(Select*fromdbo.sysobjectswhereid=object_id(N'[tb_pwd3]')andOBJECTPROPERTY(id,N'IsUserTable')=1)
droptable[tb_pwd3]
GO
--生成临时表
Selecttop256seq_no=identity(int,0,1)into#tfromsyscolumns
--生成密码3位字典表内容
Selectpwd=char(a.seq_no)+char(b.seq_no)+char(c.seq_no)intotb_pwd3from#ta,#tb,#tc
go

droptable#t

--这两种情况你要分开测试，测试第2种情况的时候你要保证你的磁盘有足够的空间，磁盘的格式要ntfs格式才行

--2、用insertinto生成大数据量的表 你可以在语句运行之前查看你的ldf文件（log）
--然后在运行之后再查看，log增长很快，而建表的速度也慢，要写log呀
ifexists(Select*fromdbo.sysobjectswhereid=object_id(N'[tb_pwd3]')andOBJECTPROPERTY(id,N'IsUserTable')=1)
droptable[tb_pwd3]
GO
createtabletb_pwd3(
pwdchar(3)
)
go
--生成临时表
Selecttop256seq_no=identity(int,0,1)into#tfromsyscolumns
--生成密码3位字典表内容
insertintotb_pwd3Selectpwd=char(a.seq_no)+char(b.seq_no)+char(c.seq_no) from#ta,#tb,#tc
go

droptable#t

附：sqlserver2000还原模型的说明
2000为我们提供了三种数据库恢复模型：simple（简单恢复），full（完全恢复），bulk_logged（大容量日志记录恢复）。
简单恢复模型最容易操作，但它是最缺乏灵活性的灾难恢复策略。选择简单恢复模型等同于把trunc.logonchkpt.设置成true。在这种恢复模型下，我们只能进行完全备份和差异备份（differentialbackup）：这是因为事务日志总是被截断，事务日志备份不可用。一般地，对于一个包含关键性数据的系统，我们不应该选择简单恢复模型，因为它不能够帮助我们把系统还原到故障点。使用这种恢复模型时，我们最多只能把系统恢复到最后一次成功进行完全备份和差异备份的状态。进行恢复时，我们首先要恢复最后一次成功进行的完全备份，然后在此基础上恢复差异备份（差异备份只能把自从数据库最后一次完全备份之后对数据库的改动施加到数据库上）。
完全恢复模型把trunc.logonchkpt.选项和SelectInto/BulkCopy选项都设置成false。完全恢复具有把数据库恢复到故障点或特定即时点的能力。对于保护那些包含关键性数据的环境来说，这种模型很理想，但它提高了设备和管理的代价，因为如果数据库访问比较频繁的话，系统将很快产生庞大的事务日志记录。由于在这种模型中SelectInto/BulkCopy设置成了false，SQLServer将记录包括大容量数据装入在内的所有事件。
最后一种恢复模型是大容量日志记录恢复，它把trunc.logonchkpt.设置成false，把SelectInto/BulkCopy设置成true。在大容量日志记录恢复模型中，大容量复制操作的数据丢失程度要比完全恢复模型严重。完全恢复模型记录大容量复制操作的完整日志，但在大容量日志记录恢复模型下，SQLServer只记录这些操作的最小日志，而且无法逐个控制这些操作。在大容量日志记录恢复模型中，数据文件损坏可能导致要求手工重做工作。下表比较了三种恢复模型的特点。恢复模型优点工作损失表现能否恢复到即时点？1