insert into tablename與Select * into tablename 比較

來源:互聯網
上載者:User
select|比較
insert into tablename 時表tablename必須存在
select * into tablename 時表不能存在

在資料庫的故障還原模型為“簡單”的時候,select * into tablename要快,因為在資料庫的故障還原模型為“簡單”的時候select * into tablename是不會產生大量日誌的


--測試:
--前提條件是資料庫的故障還原模型為“簡單”

--1、用select into 產生大資料量的表  你可以在語句運行之前查看你的ldf檔案(log)
--然後在運行之後再查看,log增長很小,而建表的速度比較快
if exists (select * from dbo.sysobjects where id = object_id(N'[tb_pwd3]') and OBJECTPROPERTY(id, N'IsUserTable') = 1)
drop table [tb_pwd3]
GO
--產生暫存資料表
select top 256 seq_no=identity(int,0,1) into #t from syscolumns
--產生密碼3位字典表內容
select pwd=char(a.seq_no)+char(b.seq_no)+char(c.seq_no) into tb_pwd3 from #t a,#t b,#t c
go

drop table #t

--這兩種情況你要分開測試,測試第2種情況的時候你要保證你的磁碟有足夠的空間,磁碟的格式要ntfs格式才行


--2、用insert into 產生大資料量的表  你可以在語句運行之前查看你的ldf檔案(log)
--然後在運行之後再查看,log增長很快,而建表的速度也慢,要寫log呀
if exists (select * from dbo.sysobjects where id = object_id(N'[tb_pwd3]') and OBJECTPROPERTY(id, N'IsUserTable') = 1)
drop table [tb_pwd3]
GO
create table tb_pwd3(
pwd char(3)
)
go
--產生暫存資料表
select top 256 seq_no=identity(int,0,1) into #t from syscolumns
--產生密碼3位字典表內容
insert into tb_pwd3 select pwd=char(a.seq_no)+char(b.seq_no)+char(c.seq_no)  from #t a,#t b,#t c
go

drop table #t

附:sql server2000還原模型的說明
SQL Server 2000為我們提供了三種資料庫恢複模型:simple(簡單恢複),full(完全恢複),bulk_logged(大容量日誌記錄恢複)。
簡單恢複模型最容易操作,但它是最缺乏靈活性的災難恢複策略。選擇簡單恢複模型等同於把trunc. log on chkpt.設定成true。在這種恢複模型下,我們只能進行完全備份和差異備份(differential backup):這是因為交易記錄總是被截斷,交易記錄備份不可用。一般地,對於一個包含關鍵性資料的系統,我們不應該選擇簡單恢複模型,因為它不能夠協助我們把系統還原到故障點。使用這種恢複模型時,我們最多隻能把系統復原到最後一次成功進行完全備份和差異備份的狀態。進行恢複時,我們首先要恢複最後一次成功進行的完全備份,然後在此基礎上恢複差異備份(差異備份只能把自從資料庫最後一次完全備份之後對資料庫的改動施加到資料庫上)。
完全恢複模型把trunc. log on chkpt.選項和Select Into/Bulk Copy選項都設定成false。完全恢複具有把資料庫恢複到故障點或特定即時點的能力。對於保護那些包含關鍵性資料的環境來說,這種模型很理想,但它提高了裝置和管理的代價,因為如果資料庫訪問比較頻繁的話,系統將很快產生龐大的交易記錄記錄。由於在這種模型中Select Into/Bulk Copy設定成了false,SQL Server將記錄包括大容量資料裝入在內的所有事件。
最後一種恢複模型是大容量日誌記錄恢複,它把trunc. log on chkpt.設定成false,把Select Into/Bulk Copy設定成true。在大容量日誌記錄恢複模型中,大量複製操作的資料丟失程度要比完全恢複模型嚴重。完全恢複模型記錄大量複製操作的完整日誌,但在大容量日誌記錄恢複模型下,SQL Server只記錄這些操作的最小日誌,而且無法逐個控制這些操作。在大容量日誌記錄恢複模型中,資料檔案損壞可能導致要求手工重做工作。 下表比較了三種恢複模型的特點。恢複模型 優點 工作損失表現 能否恢複到即時點?
簡單 允許高效能大量複製操作。
收回日誌空間,使得空間要求最小。 必須重做自最新的資料庫或差異備份後所發生的更改。 可以恢複到任何備份的結尾處。隨後必須重做更改。
完全 資料檔案丟失或損壞不會導致工作損失。
可以恢複到任意即時點(例如,應用程式或使用者錯誤之前)。 正常情況下沒有。
如果日誌損壞,則必須重做自最新的記錄備份後所發生的更改。 可以恢複到任何即時點。
大容量日誌記錄 允許高效能大量複製操作。
大容量操作使用最少的日誌空間。 如果日誌損壞,或者自最新的記錄備份後發生了大容量操作,則必須重做自上次備份後所做的更改。 否則不丟失任何工作。 可以恢複到任何備份的結尾處。隨後必須重做更改。

在資料庫的Options選項卡中,我們可以從Model下拉式清單方塊選擇Simple把恢複模型改成簡單模型。另外,Microsoft擴充了ALTER DATABASE命令,我們可以用它設定資料庫屬性。例如,用下面這個T-SQL命令可以把恢複模型設定為完全恢複模型:ALTER DATABASE Northwind SET RECOVERY FULL

 


相關文章

Alibaba Cloud 10 Year Anniversary

With You, We are Shaping a Digital World, 2009-2019

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。