sqlServer 重設(shè)c2日志保存路徑

通過數(shù)據(jù)庫修改。

成都一家集口碑和實(shí)力的網(wǎng)站建設(shè)服務(wù)商，擁有專業(yè)的企業(yè)建站團(tuán)隊(duì)和靠譜的建站技術(shù)，十年企業(yè)及個人網(wǎng)站建設(shè)經(jīng)驗(yàn) ,為成都上千客戶提供網(wǎng)頁設(shè)計制作,網(wǎng)站開發(fā),企業(yè)網(wǎng)站制作建設(shè)等服務(wù),包括成都營銷型網(wǎng)站建設(shè)，成都品牌網(wǎng)站建設(shè)，同時也為不同行業(yè)的客戶提供成都網(wǎng)站設(shè)計、做網(wǎng)站的服務(wù),包括成都電商型網(wǎng)站制作建設(shè),裝修行業(yè)網(wǎng)站制作建設(shè)，傳統(tǒng)機(jī)械行業(yè)網(wǎng)站建設(shè),傳統(tǒng)農(nóng)業(yè)行業(yè)網(wǎng)站制作建設(shè)。在成都做網(wǎng)站,選網(wǎng)站制作建設(shè)服務(wù)商就選創(chuàng)新互聯(lián)。

1、打開sqlServer客戶端，連接上數(shù)據(jù)庫。

2、選擇屬性。

3、彈出屬性對話框。

4、選擇數(shù)據(jù)庫位置修改c2日志的保存路徑。

5、打開服務(wù)。

6、右鍵點(diǎn)擊sqlserver重啟服務(wù)即可。

當(dāng)使用SQLserver時,當(dāng)連接參考已建立的表格,卻顯示引用的表無效,是什么原因

使用Hyperlink函數(shù)時，總收到報錯信息，如“引用無效”

希望實(shí)現(xiàn)這樣一種功能：單擊某個工作表名稱就直接跳轉(zhuǎn)到相應(yīng)的工作表。

可以這么做：

1、單擊C1單元格，輸入：=HYPERLINK("#'"B1"'!C2",B1)

這里使用了HYPERLINK(link_location,friendly_name)

第一個參數(shù) Link_location 是超鏈接文件的路徑和文件名，或要跳轉(zhuǎn)的單元格地址。特別要注意：

①# 表示引用的工作表在當(dāng)前工作簿中

②'"B1"'! 表示 B1 對應(yīng)的工作表，不要漏掉任何一個符號

③C2 表示的是 B1 對應(yīng)的工作表中 C2 單元格。Hyperlink 函數(shù)必須要具體鏈接到工作表中的某一單元格，不過這個單元格可以任意指定。

第二個參數(shù)是隨意指定的字符串或某一單元格的值，是你希望在超級鏈接單元格中顯示的內(nèi)容。為了示例清晰，我們?nèi)哉{(diào)用 B1 單元格的內(nèi)容。

上述參數(shù)中任一錯漏都會導(dǎo)致報錯，請一定要留心符號的輸入哦。

2、完成后單擊回車鍵，即可看到C1生成了淡藍(lán)色的超鏈接。

3、單擊超鏈接跳轉(zhuǎn)到相應(yīng)的工作表。

然后選中C1單元格，將鼠標(biāo)移動到右下角，變成黑色十字時往下拖動生成多行超鏈接。

　這樣就可以了。

如何處理SQL Server死鎖問題？

死鎖，簡而言之，兩個或者多個trans，同時請求對方正在請求的某個對象，導(dǎo)致雙方互相等待。簡單的例子如下：

trans1 trans2

------------------------------------------------------------------------

1.IDBConnection.BeginTransaction 1.IDBConnection.BeginTransaction

2.update table A 2.update table B

3.update table B 3.update table A

4.IDBConnection.Commit 4.IDBConnection.Commit

那么，很容易看到，如果trans1和trans2，分別到達(dá)了step3，那么trans1會請求對于B的X鎖，trans2會請求對于A的X鎖，而二者的鎖在step2上已經(jīng)被對方分別持有了。由于得不到鎖，后面的Commit無法執(zhí)行，這樣雙方開始死鎖。

好，我們看一個簡單的例子，來解釋一下，應(yīng)該如何解決死鎖問題。

-- Batch #1

CREATE DATABASE deadlocktest

GO

USE deadlocktest

SET NOCOUNT ON

DBCC TRACEON (1222, -1)

-- 在SQL2005中，增加了一個新的dbcc參數(shù)，就是1222，原來在2000下，我們知道，可以執(zhí)行dbcc

--traceon(1204,3605,-1)看到所有的死鎖信息。SqlServer 2005中，對于1204進(jìn)行了增強(qiáng)，這就是1222。

GO

IF OBJECT_ID ('t1') IS NOT NULL DROP TABLE t1

IF OBJECT_ID ('p1') IS NOT NULL DROP PROC p1

IF OBJECT_ID ('p2') IS NOT NULL DROP PROC p2

GO

CREATE TABLE t1 (c1 int, c2 int, c3 int, c4 char(5000))

GO

DECLARE @x int

SET @x = 1

WHILE (@x = 1000) BEGIN

INSERT INTO t1 VALUES (@x*2, @x*2, @x*2, @x*2)

SET @x = @x + 1

END

GO

CREATE CLUSTERED INDEX cidx ON t1 (c1)

CREATE NONCLUSTERED INDEX idx1 ON t1 (c2)

GO

CREATE PROC p1 @p1 int AS SELECT c2, c3 FROM t1 WHERE c2 BETWEEN @p1 AND @p1+1

GO

CREATE PROC p2 @p1 int AS

UPDATE t1 SET c2 = c2+1 WHERE c1 = @p1

UPDATE t1 SET c2 = c2-1 WHERE c1 = @p1

GO

上述sql創(chuàng)建一個deadlock的示范數(shù)據(jù)庫，插入了1000條數(shù)據(jù)，并在表t1上建立了c1列的聚集索引，和c2列的非聚集索引。另外創(chuàng)建了兩個sp，分別是從t1中select數(shù)據(jù)和update數(shù)據(jù)。

好，打開一個新的查詢窗口，我們開始執(zhí)行下面的query：

-- Batch #2

USE deadlocktest

SET NOCOUNT ON

WHILE (1=1) EXEC p2 4

GO

開始執(zhí)行后，然后我們打開第三個查詢窗口，執(zhí)行下面的query：

-- Batch #3

USE deadlocktest

SET NOCOUNT ON

CREATE TABLE #t1 (c2 int, c3 int)

GO

WHILE (1=1) BEGIN

INSERT INTO #t1 EXEC p1 4

TRUNCATE TABLE #t1

END

GO

開始執(zhí)行，哈哈，很快，我們看到了這樣的錯誤信息：

Msg 1205, Level 13, State 51, Procedure p1, Line 4

Transaction (Process ID 54) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

spid54發(fā)現(xiàn)了死鎖。

那么，我們該如何解決它？

在SqlServer 2005中，我們可以這么做：

1.在trans3的窗口中，選擇EXEC p1 4，然后right click，看到了菜單了嗎？選擇Analyse Query in Database Engine Tuning Advisor。

2.注意右面的窗口中，wordload有三個選擇：負(fù)載文件、表、查詢語句，因?yàn)槲覀冞x擇了查詢語句的方式，所以就不需要修改這個radio option了。

3.點(diǎn)左上角的Start Analysis按鈕

4.抽根煙，回來后看結(jié)果吧！出現(xiàn)了一個分析結(jié)果窗口，其中，在Index Recommendations中，我們發(fā)現(xiàn)了一條信息：大意是，在表t1上增加一個非聚集索引索引：t2+t1。

5.在當(dāng)前窗口的上方菜單上，選擇Action菜單，選擇Apply Recommendations，系統(tǒng)會自動創(chuàng)建這個索引。

重新運(yùn)行batch #3，呵呵，死鎖沒有了。

這種方式，我們可以解決大部分的Sql Server死鎖問題。那么，發(fā)生這個死鎖的根本原因是什么呢？為什么增加一個non clustered index，問題就解決了呢？ 這次，我們分析一下，為什么會死鎖呢？再回顧一下兩個sp的寫法：

CREATE PROC p1 @p1 int AS

SELECT c2, c3 FROM t1 WHERE c2 BETWEEN @p1 AND @p1+1

GO

CREATE PROC p2 @p1 int AS

UPDATE t1 SET c2 = c2+1 WHERE c1 = @p1

UPDATE t1 SET c2 = c2-1 WHERE c1 = @p1

GO

很奇怪吧！p1沒有insert，沒有delete，沒有update，只是一個select，p2才是update。這個和我們前面說過的，trans1里面updata A，update B；trans2里面upate B，update A，根本不貼邊啊！

那么，什么導(dǎo)致了死鎖？

需要從事件日志中，看sql的死鎖信息：

Spid X is running this query (line 2 of proc [p1], inputbuffer “… EXEC p1 4 …”):

SELECT c2, c3 FROM t1 WHERE c2 BETWEEN @p1 AND @p1+1

Spid Y is running this query (line 2 of proc [p2], inputbuffer “EXEC p2 4”):

UPDATE t1 SET c2 = c2+1 WHERE c1 = @p1

The SELECT is waiting for a Shared KEY lock on index t1.cidx. The UPDATE holds a conflicting X lock.

The UPDATE is waiting for an eXclusive KEY lock on index t1.idx1. The SELECT holds a conflicting S lock.

首先，我們看看p1的執(zhí)行計劃。怎么看呢？可以執(zhí)行set statistics profile on，這句就可以了。下面是p1的執(zhí)行計劃

SELECT c2, c3 FROM t1 WHERE c2 BETWEEN @p1 AND @p1+1

|--Nested Loops(Inner Join, OUTER REFERENCES:([Uniq1002], [t1].[c1]))

|--Index Seek(OBJECT:([t1].[idx1]), SEEK:([t1].[c2] = [@p1] AND [t1].[c2] = [@p1]+(1)) ORDERED FORWARD)

|--Clustered Index Seek(OBJECT:([t1].[cidx]), SEEK:([t1].[c1]=[t1].[c1] AND [Uniq1002]=[Uniq1002]) LOOKUP ORDERED FORWARD)

我們看到了一個nested loops，第一行，利用索引t1.c2來進(jìn)行seek，seek出來的那個rowid，在第二行中，用來通過聚集索引來查找整行的數(shù)據(jù)。這是什么？就是bookmark lookup啊！為什么？因?yàn)槲覀冃枰腸2、c3不能完全的被索引t1.c1帶出來，所以需要書簽查找。

好，我們接著看p2的執(zhí)行計劃。

UPDATE t1 SET c2 = c2+1 WHERE c1 = @p1

|--Clustered Index Update(OBJECT:([t1].[cidx]), OBJECT:([t1].[idx1]), SET:([t1].[c2] = [Expr1004]))

|--Compute Scalar(DEFINE:([Expr1013]=[Expr1013]))

|--Compute Scalar(DEFINE:([Expr1004]=[t1].[c2]+(1), [Expr1013]=CASE WHEN CASE WHEN ...

|--Top(ROWCOUNT est 0)

|--Clustered Index Seek(OBJECT:([t1].[cidx]), SEEK:([t1].[c1]=[@p1]) ORDERED FORWARD)

通過聚集索引的seek找到了一行，然后開始更新。這里注意的是，update的時候，它會申請一個針對clustered index的X鎖的。

實(shí)際上到這里，我們就明白了為什么update會對select產(chǎn)生死鎖。update的時候，會申請一個針對clustered index的X鎖，這樣就阻塞住了（注意，不是死鎖！）select里面最后的那個clustered index seek。死鎖的另一半在哪里呢？注意我們的select語句，c2存在于索引idx1中，c1是一個聚集索引cidx。問題就在這里！我們在p2中更新了c2這個值，所以sqlserver會自動更新包含c2列的非聚集索引：idx1。而idx1在哪里？就在我們剛才的select語句中。而對這個索引列的更改，意味著索引集合的某個行或者某些行，需要重新排列，而重新排列，需要一個X鎖。

SO………，問題就這樣被發(fā)現(xiàn)了。

總結(jié)一下，就是說，某個query使用非聚集索引來select數(shù)據(jù)，那么它會在非聚集索引上持有一個S鎖。當(dāng)有一些select的列不在該索引上，它需要根據(jù)rowid找到對應(yīng)的聚集索引的那行，然后找到其他數(shù)據(jù)。而此時，第二個的查詢中，update正在聚集索引上忙乎：定位、加鎖、修改等。但因?yàn)檎谛薷牡哪硞€列，是另外一個非聚集索引的某個列，所以此時，它需要同時更改那個非聚集索引的信息，這就需要在那個非聚集索引上，加第二個X鎖。select開始等待update的X鎖，update開始等待select的S鎖，死鎖，就這樣發(fā)生鳥。

那么，為什么我們增加了一個非聚集索引，死鎖就消失鳥？我們看一下，按照上文中自動增加的索引之后的執(zhí)行計劃：

SELECT c2, c3 FROM t1 WHERE c2 BETWEEN @p1 AND @p1+1

|--Index Seek(OBJECT:([deadlocktest].[dbo].[t1].[_dta_index_t1_7_2073058421__K2_K1_3]), SEEK:([deadlocktest].[dbo].[t1].[c2] = [@p1] AND [deadlocktest].[dbo].[t1].[c2] = [@p1]+(1)) ORDERED FORWARD)

哦，對于clustered index的需求沒有了，因?yàn)樵黾拥母采w索引已經(jīng)足夠把所有的信息都select出來。就這么簡單。

實(shí)際上，在sqlserver 2005中，如果用profiler來抓eventid：1222，那么會出現(xiàn)一個死鎖的圖，很直觀的說。

下面的方法，有助于將死鎖減至最少（詳細(xì)情況，請看SQLServer聯(lián)機(jī)幫助，搜索：將死鎖減至最少即可。

按同一順序訪問對象。

避免事務(wù)中的用戶交互。

保持事務(wù)簡短并處于一個批處理中。

使用較低的隔離級別。

使用基于行版本控制的隔離級別。

將 READ_COMMITTED_SNAPSHOT 數(shù)據(jù)庫選項(xiàng)設(shè)置為 ON，使得已提交讀事務(wù)使用行版本控制。

使用快照隔離。

使用綁定連接。

如何處理SQL Server死鎖問題

死鎖，簡而言之，兩個或者多個trans，同時請求對方正在請求的某個對象，導(dǎo)致雙方互相等待。簡單的例子如下：

trans1 trans2

------------------------------------------------------------------------

1.IDBConnection.BeginTransaction 1.IDBConnection.BeginTransaction

2.update table A 2.update table B

3.update table B 3.update table A

4.IDBConnection.Commit 4.IDBConnection.Commit

那么，很容易看到，如果trans1和trans2，分別到達(dá)了step3，那么trans1會請求對于B的X鎖，trans2會請求對于A的X鎖，而二者的鎖在step2上已經(jīng)被對方分別持有了。由于得不到鎖，后面的Commit無法執(zhí)行，這樣雙方開始死鎖。

好，我們看一個簡單的例子，來解釋一下，應(yīng)該如何解決死鎖問題。

-- Batch #1

CREATE DATABASE deadlocktest

GO

USE deadlocktest

SET NOCOUNT ON

DBCC TRACEON (1222, -1)

-- 在SQL2005中，增加了一個新的dbcc參數(shù)，就是1222，原來在2000下，我們知道，可以執(zhí)行dbcc

--traceon(1204,3605,-1)看到所有的死鎖信息。SqlServer 2005中，對于1204進(jìn)行了增強(qiáng)，這就是1222。

GO

IF OBJECT_ID ('t1') IS NOT NULL DROP TABLE t1

IF OBJECT_ID ('p1') IS NOT NULL DROP PROC p1

IF OBJECT_ID ('p2') IS NOT NULL DROP PROC p2

GO

CREATE TABLE t1 (c1 int, c2 int, c3 int, c4 char(5000))

GO

DECLARE @x int

SET @x = 1

WHILE (@x = 1000) BEGIN

INSERT INTO t1 VALUES (@x*2, @x*2, @x*2, @x*2)

SET @x = @x + 1

END

GO

CREATE CLUSTERED INDEX cidx ON t1 (c1)

CREATE NONCLUSTERED INDEX idx1 ON t1 (c2)

GO

CREATE PROC p1 @p1 int AS SELECT c2, c3 FROM t1 WHERE c2 BETWEEN @p1 AND @p1+1

GO

CREATE PROC p2 @p1 int AS

UPDATE t1 SET c2 = c2+1 WHERE c1 = @p1

UPDATE t1 SET c2 = c2-1 WHERE c1 = @p1

GO

上述sql創(chuàng)建一個deadlock的示范數(shù)據(jù)庫，插入了1000條數(shù)據(jù)，并在表t1上建立了c1列的聚集索引，和c2列的非聚集索引。另外創(chuàng)建了兩個sp，分別是從t1中select數(shù)據(jù)和update數(shù)據(jù)。

好，打開一個新的查詢窗口，我們開始執(zhí)行下面的query：

-- Batch #2

USE deadlocktest

SET NOCOUNT ON

WHILE (1=1) EXEC p2 4

GO

開始執(zhí)行后，然后我們打開第三個查詢窗口，執(zhí)行下面的query：

-- Batch #3

USE deadlocktest

SET NOCOUNT ON

CREATE TABLE #t1 (c2 int, c3 int)

GO

WHILE (1=1) BEGIN

INSERT INTO #t1 EXEC p1 4

TRUNCATE TABLE #t1

END

GO

開始執(zhí)行，哈哈，很快，我們看到了這樣的錯誤信息：

Msg 1205, Level 13, State 51, Procedure p1, Line 4

Transaction (Process ID 54) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

spid54發(fā)現(xiàn)了死鎖。

那么，我們該如何解決它？

在SqlServer 2005中，我們可以這么做：

1.在trans3的窗口中，選擇EXEC p1 4，然后right click，看到了菜單了嗎？選擇Analyse Query in Database Engine Tuning Advisor。

2.注意右面的窗口中，wordload有三個選擇：負(fù)載文件、表、查詢語句，因?yàn)槲覀冞x擇了查詢語句的方式，所以就不需要修改這個radio option了。

3.點(diǎn)左上角的Start Analysis按鈕

4.抽根煙，回來后看結(jié)果吧！出現(xiàn)了一個分析結(jié)果窗口，其中，在Index Recommendations中，我們發(fā)現(xiàn)了一條信息：大意是，在表t1上增加一個非聚集索引索引：t2+t1。

5.在當(dāng)前窗口的上方菜單上，選擇Action菜單，選擇Apply Recommendations，系統(tǒng)會自動創(chuàng)建這個索引。

重新運(yùn)行batch #3，呵呵，死鎖沒有了。

這種方式，我們可以解決大部分的Sql Server死鎖問題。那么，發(fā)生這個死鎖的根本原因是什么呢？為什么增加一個non clustered index，問題就解決了呢？ 這次，我們分析一下，為什么會死鎖呢？再回顧一下兩個sp的寫法：

CREATE PROC p1 @p1 int AS

SELECT c2, c3 FROM t1 WHERE c2 BETWEEN @p1 AND @p1+1

GO

CREATE PROC p2 @p1 int AS

UPDATE t1 SET c2 = c2+1 WHERE c1 = @p1

UPDATE t1 SET c2 = c2-1 WHERE c1 = @p1

GO

很奇怪吧！p1沒有insert，沒有delete，沒有update，只是一個select，p2才是update。這個和我們前面說過的，trans1里面updata A，update B；trans2里面upate B，update A，根本不貼邊啊！

那么，什么導(dǎo)致了死鎖？

需要從事件日志中，看sql的死鎖信息：

Spid X is running this query (line 2 of proc [p1], inputbuffer “… EXEC p1 4 …”):

SELECT c2, c3 FROM t1 WHERE c2 BETWEEN @p1 AND @p1+1

Spid Y is running this query (line 2 of proc [p2], inputbuffer “EXEC p2 4”):

UPDATE t1 SET c2 = c2+1 WHERE c1 = @p1

The SELECT is waiting for a Shared KEY lock on index t1.cidx. The UPDATE holds a conflicting X lock.

The UPDATE is waiting for an eXclusive KEY lock on index t1.idx1. The SELECT holds a conflicting S lock.

首先，我們看看p1的執(zhí)行計劃。怎么看呢？可以執(zhí)行set statistics profile on，這句就可以了。下面是p1的執(zhí)行計劃

SELECT c2, c3 FROM t1 WHERE c2 BETWEEN @p1 AND @p1+1

|--Nested Loops(Inner Join, OUTER REFERENCES:([Uniq1002], [t1].[c1]))

|--Index Seek(OBJECT:([t1].[idx1]), SEEK:([t1].[c2] = [@p1] AND [t1].[c2] = [@p1]+(1)) ORDERED FORWARD)

|--Clustered Index Seek(OBJECT:([t1].[cidx]), SEEK:([t1].[c1]=[t1].[c1] AND [Uniq1002]=[Uniq1002]) LOOKUP ORDERED FORWARD)

我們看到了一個nested loops，第一行，利用索引t1.c2來進(jìn)行seek，seek出來的那個rowid，在第二行中，用來通過聚集索引來查找整行的數(shù)據(jù)。這是什么？就是bookmark lookup啊！為什么？因?yàn)槲覀冃枰腸2、c3不能完全的被索引t1.c1帶出來，所以需要書簽查找。

好，我們接著看p2的執(zhí)行計劃。

UPDATE t1 SET c2 = c2+1 WHERE c1 = @p1

|--Clustered Index Update(OBJECT:([t1].[cidx]), OBJECT:([t1].[idx1]), SET:([t1].[c2] = [Expr1004]))

|--Compute Scalar(DEFINE:([Expr1013]=[Expr1013]))

|--Compute Scalar(DEFINE:([Expr1004]=[t1].[c2]+(1), [Expr1013]=CASE WHEN CASE WHEN ...

|--Top(ROWCOUNT est 0)

|--Clustered Index Seek(OBJECT:([t1].[cidx]), SEEK:([t1].[c1]=[@p1]) ORDERED FORWARD)

通過聚集索引的seek找到了一行，然后開始更新。這里注意的是，update的時候，它會申請一個針對clustered index的X鎖的。

實(shí)際上到這里，我們就明白了為什么update會對select產(chǎn)生死鎖。update的時候，會申請一個針對clustered index的X鎖，這樣就阻塞住了（注意，不是死鎖！）select里面最后的那個clustered index seek。死鎖的另一半在哪里呢？注意我們的select語句，c2存在于索引idx1中，c1是一個聚集索引cidx。問題就在這里！我們在p2中更新了c2這個值，所以sqlserver會自動更新包含c2列的非聚集索引：idx1。而idx1在哪里？就在我們剛才的select語句中。而對這個索引列的更改，意味著索引集合的某個行或者某些行，需要重新排列，而重新排列，需要一個X鎖。

SO………，問題就這樣被發(fā)現(xiàn)了。

總結(jié)一下，就是說，某個query使用非聚集索引來select數(shù)據(jù)，那么它會在非聚集索引上持有一個S鎖。當(dāng)有一些select的列不在該索引上，它需要根據(jù)rowid找到對應(yīng)的聚集索引的那行，然后找到其他數(shù)據(jù)。而此時，第二個的查詢中，update正在聚集索引上忙乎：定位、加鎖、修改等。但因?yàn)檎谛薷牡哪硞€列，是另外一個非聚集索引的某個列，所以此時，它需要同時更改那個非聚集索引的信息，這就需要在那個非聚集索引上，加第二個X鎖。select開始等待update的X鎖，update開始等待select的S鎖，死鎖，就這樣發(fā)生鳥。

那么，為什么我們增加了一個非聚集索引，死鎖就消失鳥？我們看一下，按照上文中自動增加的索引之后的執(zhí)行計劃：

SELECT c2, c3 FROM t1 WHERE c2 BETWEEN @p1 AND @p1+1

|--Index Seek(OBJECT:([deadlocktest].[dbo].[t1].[_dta_index_t1_7_2073058421__K2_K1_3]), SEEK:([deadlocktest].[dbo].[t1].[c2] = [@p1] AND [deadlocktest].[dbo].[t1].[c2] = [@p1]+(1)) ORDERED FORWARD)

哦，對于clustered index的需求沒有了，因?yàn)樵黾拥母采w索引已經(jīng)足夠把所有的信息都select出來。就這么簡單。

實(shí)際上，在sqlserver 2005中，如果用profiler來抓eventid：1222，那么會出現(xiàn)一個死鎖的圖，很直觀的說。

下面的方法，有助于將死鎖減至最少（詳細(xì)情況，請看SQLServer聯(lián)機(jī)幫助，搜索：將死鎖減至最少即可。

按同一順序訪問對象。

避免事務(wù)中的用戶交互。

保持事務(wù)簡短并處于一個批處理中。

使用較低的隔離級別。

使用基于行版本控制的隔離級別。

將 READ_COMMITTED_SNAPSHOT 數(shù)據(jù)庫選項(xiàng)設(shè)置為 ON，使得已提交讀事務(wù)使用行版本控制。

使用快照隔離。

使用綁定連接。

“sqlserver”三表聯(lián)如何查詢“sql”語句？

假設(shè)學(xué)生表叫student,課程表叫class,選課表叫choose

1.三層嵌套的問題

select student.name from student where student.id IN

(select choose.sid from choose where choose.cid NOT IN

(select class.id from class where class.teacher='李明'))

2.一個內(nèi)連接，一個嵌套

select student.name,avg(choose.score) from

student inner join choose on student.id=choose.sid

where student.id IN

(select choose.sid from choose

where choose.score'60'

group by choose.sid

having count(choose.sid)=2)

gruop by student.id

3.一個聯(lián)合查詢，一個嵌套查詢

select student.name from student

where student.id IN

(select c1.sid from choose c1 where choose.cid='1'

union

select c2.sid from choose c2 where choose.cid='2'

on c1.sid=c2.sid

)

4.其實(shí)就是自連接查詢和行列交換的問題：

select student.id,

(case choose.id when '1' then choose.score end) as 1號課成績,

(case choose.id when '2' then choose.score end) as 2號課成績,

from student inner join choose on student.id=choose.sid sc1,

student inner join choose on student.id=choose.sid sc2

where sc1.id='1'

and sc2.id='2'

and sc1.scoresc2.score

當(dāng)前題目：c2sqlserver的簡單介紹
網(wǎng)站路徑：http://chinadenli.net/article24/dsiioce.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供自適應(yīng)網(wǎng)站、品牌網(wǎng)站設(shè)計、網(wǎng)站設(shè)計公司、建站公司、服務(wù)器托管、做網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)