1. SQL Server導入導出向導,這種方式是最方便的.
導入向導,微軟提供了多種數據源驅動,包括SQL Server Native Cliant, OLE DB For Oracle,Flat File Source,Access,Excel,XML等,基本上可以滿足系統開發的需求.
同樣導出向導也有同樣多的目的源驅動,可以把數據導入到不同的目的源.
對資料庫管理人員來說這種方式簡單容易操作,導入時SQL Server也會幫你建立相同結構的Table.
2. 用.NET的代碼實現(比如有一個txt或是excel的檔案,到讀取到DB中)
2.1 最為常見的就是循環讀取txt的內容,然後一條一條的塞入到Table中.這里不再贅述.
2.2 集合整體讀取,使用OLEDB驅動.
代碼如下:
代碼
string strOLEDBConnect = @"Provider=Microsoft.Jet.OLEDB.4.0;Data Source=D:\1\;Extended Properties='text;HDR=Yes;FMT=Delimited'";
OleDbConnection conn = new OleDbConnection(strOLEDBConnect);
conn.Open();
SQLstmt = "select * from 1.txt";//讀取.txt中的數據
DataTable dt=new DataTable();
OleDbDataAdapter da = new OleDbDataAdapter(SQLstmt, conn);
da.Fill(dt);//在DataSet的指定范圍中添加或刷新行以匹配使用DataSet、DataTable 和IDataReader 名稱的數據源中的行。
if(dt.Rows.Count>0)
foreach(DataRow dr in dt.Rows)
{
SQLstmt = "insert into MyTable values('" + dr..."
3.BCP,可以用作大容量的數據導入導出,也可以配合來使用.
語法:
代碼
bcp {[[database_name.][schema].]{table_name | view_name} | "query"}
{in | out | queryout | format} data_file
[-mmax_errors] [-fformat_file] [-x] [-eerr_file]
[-Ffirst_row] [-Llast_row] [-bbatch_size]
[-ddatabase_name] [-n] [-c] [-N] [-w] [-V (70 | 80 | 90 )]
[-q] [-C { ACP | OEM | RAW | code_page } ] [-tfield_term]
[-rrow_term] [-iinput_file] [-ooutput_file] [-apacket_size]
[-S [server_name[\instance_name]]] [-Ulogin_id] [-Ppassword]
[-T] [-v] [-R] [-k] [-E] [-h"hint [,...n]"]
請注意數據導入導出的方向參數:in,out,queryout
如:
如:
4.BULK INSERT. T-SQL的命令,允許直接導入數據
語法:
BULK INSERT
[ database_name. [ schema_name ] . | schema_name. ] [ table_name | view_name ]
FROM 'data_file'
[ WITH
(
[ [ , ] BATCHSIZE =batch_size ]
[ [ , ] CHECK_CONSTRAINTS ]
[ [ , ] CODEPAGE = { 'ACP' | 'OEM' | 'RAW' | 'code_page' } ]
[ [ , ] DATAFILETYPE =
{ 'char' | 'native'| 'widechar' | 'widenative' } ]
[ [ , ] FIELDTERMINATOR = 'field_terminator' ]
[ [ , ] FIRSTROW = first_row ]
[ [ , ] FIRE_TRIGGERS ]
[ [ , ] FORMATFILE ='format_file_path' ]
[ [ , ] KEEPIDENTITY ]
[ [ , ] KEEPNULLS ]
[ [ , ] KILOBYTES_PER_BATCH =kilobytes_per_batch ]
[ [ , ] LASTROW =last_row ]
[ [ , ] MAXERRORS =max_errors ]
[ [ , ] ORDER ( { column [ ASC | DESC ] } [ ,...n ] ) ]
[ [ , ] ROWS_PER_BATCH =rows_per_batch ]
[ [ , ] ROWTERMINATOR ='row_terminator' ]
[ [ , ] TABLOCK ]
[ [ , ] ERRORFILE ='file_name' ]
)]
重要參數:
FIELDTERMINATOR,欄位分隔符
FIRSTROW:第一個數據行
ROWTERMINATOR:行終結符
如:
BULK INSERT dbo.ImportTest
FROM 'C:\ImportData.txt'
WITH ( FIELDTERMINATOR =',', FIRSTROW = 2 )
5. OPENROWSET也是T-SQL的命令,包含有DB連接的信息和其它導入方法不同的是,OPENROWSET可以作為一個目標表參與INSERT,UPDATE,DELETE操作.
語法:
OPENROWSET
( { 'provider_name', { 'datasource';'user_id';'password'
| 'provider_string' }
, { [ catalog. ] [ schema. ] object
| 'query'
}
| BULK 'data_file',
{ FORMATFILE ='format_file_path' [ <bulk_options> ]
| SINGLE_BLOB | SINGLE_CLOB | SINGLE_NCLOB }
} )<bulk_options> ::=
[ , CODEPAGE = { 'ACP' | 'OEM' | 'RAW' | 'code_page' } ]
[ , ERRORFILE ='file_name' ]
[ , FIRSTROW = first_row ]
[ , LASTROW = last_row ]
[ , MAXERRORS = maximum_errors ]
[ , ROWS_PER_BATCH =rows_per_batch ]
如:
INSERT INTO dbo.ImportTest
SELECT * FROM OPENROWSET('Microsoft.Jet.OLEDB.4.0',
'Excel 8.0;Database=C:\ImportData.xls', 'SELECT * FROM [Sheet1$]') WHERE A1 IS NOT NULL
6.OPENDATASOURCE
語法:
OPENDATASOURCE ( provider_name,init_string )
如:
INSERT INTO dbo.ImportTest
SELECT * FROM OPENDATASOURCE('Microsoft.Jet.OLEDB.4.0',
'Data Source=C:\ImportData.xls;Extended Properties=Excel 8.0')...[Sheet1$]
7.OPENQUERY.是在linked server的基礎上執行的查詢.所以執行之前必須先建立好link server.OPENQUERY的結果集可以作為一個table參與DML的操作.
語法:
OPENQUERY (linked_server ,'query')
如:
EXEC sp_addlinkedserver 'ImportData',
'Jet 4.0', 'Microsoft.Jet.OLEDB.4.0',
'C:\ImportData.xls',
NULL,
'Excel 8.0'
GO
INSERT INTO dbo.ImportTest
SELECT *
FROM OPENQUERY(ImportData, 'SELECT * FROM [Sheet1$]')
⑵ SQLServer求優化
我一不太會優化，提供你一些優化的方法吧
操作符優化
in 操作符
用in寫出來的sql的優點是比較容易寫及清晰易懂，這比較適合現代軟體開發的風格。
但是用in的sql性能總是比較低的，從oracle執行的步驟來分析用in的sql與不用in的sql有以下區別：
oracle試圖將其轉換成多個表的連接，如果轉換不成功則先執行in裡面的子查詢，再查詢外層的表記錄，如果轉換成功則直接採用多個表的連接方式查詢。由此可見用in的sql至少多了一個轉換的過程。一般的sql都可以轉換成功，但對於含有分組統計等方面的sql就不能轉換了。
推薦方案：在業務密集的sql當中盡量不採用in操作符。
not in操作符
此操作是強列推薦不使用的，因為它不能應用表的索引。
推薦方案：用not exists 或（外連接+判斷為空）方案代替
<> 操作符（不等於）
不等於操作符是永遠不會用到索引的，因此對它的處理只會產生全表掃描。
推薦方案：用其它相同功能的操作運算代替，如
a<>0 改為 a>0 or a<0
a<>』』 改為 a>』』
is null 或is not null操作（判斷欄位是否為空）
判斷欄位是否為空一般是不會應用索引的，因為b樹索引是不索引空值的。
推薦方案：用其它相同功能的操作運算代替，如
a is not null 改為 a>0 或a>』』等。
不允許欄位為空，而用一個預設值代替空值，如業擴申請中狀態欄位不允許為空，預設為申請。
建立點陣圖索引（有分區的表不能建，點陣圖索引比較難控制，如欄位值太多索引會使性能下降，多人更新操作會增加數據塊鎖的現象）
> 及 < 操作符（大於或小於操作符）
大於或小於操作符一般情況下是不用調整的，因為它有索引就會採用索引查找，但有的情況下可以對它進行優化，如一個表有100萬記錄，一個數值型欄位a，30萬記錄的a=0，30萬記錄的a=1，39萬記錄的a=2，1萬記錄的a=3。那麼執行a>2與a>=3的效果就有很大的區別了，因為a>2時oracle會先找出為2的記錄索引再進行比較，而a>=3時oracle則直接找到=3的記錄索引。
like操作符
like操作符可以應用通配符查詢，裡面的通配符組合可能達到幾乎是任意的查詢，但是如果用得不好則會產生性能上的問題，如like 『%5400%』 這種查詢不會引用索引，而like 『x5400%』則會引用范圍索引。一個實際例子：用yw_yhjbqk表中營業編號後面的戶標識號可來查詢營業編號 yy_bh like 『%5400%』 這個條件會產生全表掃描，如果改成yy_bh like 』x5400%』 or yy_bh like 』b5400%』 則會利用yy_bh的索引進行兩個范圍的查詢，性能肯定大大提高。
union操作符
union在進行表鏈接後會篩選掉重復的記錄，所以在表鏈接後會對所產生的結果集進行排序運算，刪除重復的記錄再返回結果。實際大部分應用中是不會產生重復的記錄，最常見的是過程表與歷史表union。如：
select * from gc_dfys
union
select * from ls_jg_dfys
這個sql在運行時先取出兩個表的結果，再用排序空間進行排序刪除重復的記錄，最後返回結果集，如果表數據量大的話可能會導致用磁碟進行排序。
推薦方案：採用union all操作符替代union，因為union all操作只是簡單的將兩個結果合並後就返回。
select * from gc_dfys
union all
select * from ls_jg_dfys
sql語句索引的利用
對條件欄位的一些優化
採用函數處理的欄位不能利用索引，如：
substr(hbs_bh,1,4)=』5400』，優化處理：hbs_bh like 『5400%』
trunc(sk_rq)=trunc(sysdate)， 優化處理：
sk_rq>=trunc(sysdate) and sk_rq
進行了顯式或隱式的運算的欄位不能進行索引，如：
ss_df+20>50，優化處理：ss_df>30
『x』||hbs_bh>』x5400021452』，優化處理：hbs_bh>』5400021542』
sk_rq+5=sysdate，優化處理：sk_rq=sysdate-5
hbs_bh=5401002554，優化處理：hbs_bh=』 5401002554』，註：此條件對hbs_bh 進行隱式的to_number轉換，因為hbs_bh欄位是字元型。
條件內包括了多個本表的欄位運算時不能進行索引，如：
ys_df>cx_df，無法進行優化
qc_bh||kh_bh=』5400250000』，優化處理：qc_bh=』5400』 and kh_bh=』250000』
應用oracle的hint（提示）處理
提示處理是在oracle產生的sql分析執行路徑不滿意的情況下要用到的。它可以對sql進行以下方面的提示
目標方面的提示：
cost（按成本優化）
rule（按規則優化）
choose（預設）（oracle自動選擇成本或規則進行優化）
all_rows（所有的行盡快返回）
first_rows（第一行數據盡快返回）
執行方法的提示：
use_nl（使用nested loops方式聯合）
use_merge（使用merge join方式聯合）
use_hash（使用hash join方式聯合）
索引提示：
index（table index）（使用提示的表索引進行查詢）
其它高級提示（如並行處理等等）
oracle的提示功能是比較強的功能，也是比較復雜的應用，並且提示只是給oracle執行的一個建議，有時如果出於成本方面的考慮oracle也可能不會按提示進行。根據實踐應用，一般不建議開發人員應用oracle提示，因為各個資料庫及伺服器性能情況不一樣，很可能一個地方性能提升了，但另一個地方卻下降了，oracle在sql執行分析方面已經比較成熟，如果分析執行的路徑不對首先應在資料庫結構（主要是索引）、伺服器當前性能（共享內存、磁碟文件碎片）、資料庫對象（表、索引）統計信息是否正確這幾方面分析。
⑶ sqlserver鎖表機制
這個問題要具體分析：
第一，事務隔離級別基本兩種模式，一種是阻塞式（read committed，repeatable read，serializable）
，一種是非阻塞式(read uncommitted,snapshot)。
默認是read committed，這種情況一般在更新表的時候，如果不使用hint 提示，基本是先對表添加IX鎖，級別不算高，基本和其他鎖兼容，但是repeatable read，serializable 事務隔離級別就會先對表添加IX鎖，然後向X鎖轉化，而X鎖和大多數鎖都不兼容，容易發生表阻塞。
第二種隔離級別不會有以上問題，但是又引入了其它的問題。
以上是一種情況。
另外一種就是 鎖升級，一個鎖是96B內存，如果太多，sqlserver就會升級為表鎖，一般是5000以上行級鎖就升級為一個表X鎖。
所以適當的文件分組和表分區 是有必要的。
其次就是資源互相引用導致事務長時間不能釋放，導致真正的死鎖，不過SQL2005以後，這種情況發生的概率很低。
留個問題你自己去想。
兩個SQL，兩個連接，同時執行。
update A set A.NAME=xxx where A.id=55
update A set A.NAME=xxx where A.id=56, 如果 56 不存在你說會發生什麼情況呢？
⑷ sqlserver怎麼導出資料庫
材料/工具：SQL Server
1、打開SQL Server，找到需要導出的資料庫。
⑸ 如何更改SQL中某列的值
通過update方法實現。
sql：update table tablename t set filename =值1 where t.name='條件'。
解釋：更改某列，說明有條件，所有必須通過「where」條件語句定位到列。定位成功後，通過set方法給固定欄位賦值即可。
上面sql語句的意思：更改tablename 表中name值為「條件」的記錄，將「filename 」的值改為「值1」。
⑹ 揭秘SQL Server 2014有哪些新特性
1、內存資料庫
在傳統的資料庫表中，由於磁碟的物理結構限制，表和索引的結構為B-Tree，這就使得該類索引在大並發的OLTP環境中顯得非常乏力，雖然有很多辦法來解決這類問題，比如說樂觀並發控制，應用程序緩存，分布式等。但成本依然會略高。而隨著這些年硬體的發展，現在伺服器擁有幾百G內存並不罕見，此外由於NUMA架構的成熟，也消除了多CPU訪問內存的瓶頸問題，因此內存資料庫得以出現。
內存的學名叫做RandomAccess Memory（RAM），因此如其特性一樣，是隨機訪問的，因此對於內存，對應的數據結構也會是Hash-Index，而並發的隔離方式也對應的變成了MVCC，因此內存資料庫可以在同樣的硬體資源下，Handle更多的並發和請求，並且不會被鎖阻塞，而SQLServer 2014集成了這個強大的功能，並不像Oracle的TimesTen需要額外付費，因此結合SSDAS Buffer Pool特性，所產生的效果將會非常值得期待。
SQLServer內存資料庫的表現形式
在SQL Server的Hekaton引擎由兩部分組成：內存優化表和本地編譯存儲過程。雖然Hekaton集成進了關系資料庫引擎，但訪問他們的方法對於客戶端是透明的，這也意味著從客戶端應用程序的角度來看，並不會知道Hekaton引擎的存在。如圖1所示。
圖8.內存優化表+本地編譯存儲過程
因此不難看出，內存優化表+本地編譯存儲過程有接近幾十倍的性能提升。
⑺ sqlserver update語句怎樣更改兩個數據
UPDATE是我們常SQL語句之一,update主要用於更改表中的現有數據.
UPDATE詳細語法
{
table_name WITH ( < table_hint_limited > [ ...n ] )
| view_name
| rowset_function_limited
}
SET
{ column_name = { expression | DEFAULT | NULL }
| @variable = expression
| @variable = column = expression } [ ,...n ]
{ { [ FROM { < table_source > } [ ,...n ] ]
[ WHERE
< search_condition > ] }
|
[ WHERE CURRENT OF
{ { [ GLOBAL ] cursor_name } | cursor_variable_name }
] }
[ OPTION ( < query_hint > [ ,...n ] ) ]
< table_source > ::=
table_name [ [ AS ] table_alias ] [ WITH ( < table_hint > [ ,...n ] ) ]
| view_name [ [ AS ] table_alias ]
| rowset_function [ [ AS ] table_alias ]
| derived_table [ AS ] table_alias [ ( column_alias [ ,...n ] ) ]
| < joined_table >
< joined_table > ::=
< table_source > < join_type > < table_source > ON < search_condition >
| < table_source > CROSS JOIN < table_source >
| < joined_table >
< join_type > ::=
[ INNER | { { LEFT | RIGHT | FULL } [OUTER] } ]
[ < join_hint > ]
JOIN
< table_hint_limited > ::=
{ FASTFIRSTROW
| HOLDLOCK
| PAGLOCK
| READCOMMITTED
| REPEATABLEREAD
| ROWLOCK
| SERIALIZABLE
| TABLOCK
| TABLOCKX
| UPDLOCK
}
< table_hint > ::=
{ INDEX ( index_val [ ,...n ] )
| FASTFIRSTROW
| HOLDLOCK
| NOLOCK
| PAGLOCK
| READCOMMITTED
| READPAST
| READUNCOMMITTED
| REPEATABLEREAD
| ROWLOCK
| SERIALIZABLE
| TABLOCK
| TABLOCKX
| UPDLOCK
}
< query_hint > ::=
{ { HASH | ORDER } GROUP
| { CONCAT | HASH | MERGE } UNION
| {LOOP | MERGE | HASH } JOIN
| FAST number_rows
| FORCE ORDER
| MAXDOP
| ROBUST PLAN
| KEEP PLAN
}