⑴ 如何查看sqlServer查詢語句的執行效率
使用語句查詢SQL Server執行過的語句及執行效率
SELECTTOP1000
ST.textAS'執行的SQL語句',
QS.execution_countAS'執行次數',
QS.total_elapsed_timeAS'耗時',
QS.total_logical_readsAS'邏輯讀取次數',
QS.total_logical_writesAS'邏輯寫入次數',
QS.total_physical_readsAS'物理讀取次數',
QS.creation_timeAS'執行時間',
QS.*
FROMsys.dm_exec_query_statsQS
CROSSAPPLY
sys.dm_exec_sql_text(QS.sql_handle)ST
--WHEREQS.creation_timeBETWEEN'2015-08-0100:00:00'AND'2015-09-0211:00:00'
ORDERBY
QS.creation_timeDESC
⑵ 簡單的SqlServer語句求解釋！！！
--從sc表中獲取每個cno的數量
Selectcno,count(sno)--獲取cno，及每個cno的數量
Fromsc--表名
Groupbycno;--按cno分組
⑶ sql語句 sqlserver
朋友，sqlserver中不允許有兩條相同的數據行存在，當你在插入數據時，如果插入的兩條相同數據，系統將提示你：「列信息不足！」，這時候你只要插入一行自動增長行作為主鍵即可解決此問題，所以你這個問題只能查詢一個相對相同的值，即是：一行中大部分欄位相同的情況，語句如下：
select * from table1 a,table1 b where a.id =b.id and a.col1=b.col1 and a.col2 = b.col2;
這是一個自聯接，即：表自己與自己作聯接查詢，如果還要查的更精確，可以在where後面加更多的欄位來確定選定的行。
請好好理解這些概念，祝你成功 ^ ^)
⑷ 如何查看sqlserver執行計劃來判斷SQL語句效率
對於執行計劃，特別是2008，先看看有沒有丟失索引。然後看執行計劃裡面的圖標，哪個的百分比是最大的。重點優化那個。還要看有沒有表掃描、聚集索引掃描等。執行計劃是一本書才勉強說得完的東西。
⑸ sql語句分析。（名牌大學考試題）
首先要說，這些語法都是基於SQLSERVER資料庫的語法，DATEDIFF TOP等，在ORACLE等其他資料庫是沒有的。
1. 主要是datediff函數的用法，獲取兩個日期之間的時間差，可以得到年月日小時分秒等等，可以參看這個函數的說明。
這里第一個參數表示獲取時間差的類型，minute表示獲取兩個日期的時間差是分鍾。
第二個參數是起始時間，第二個是截止時間，都是datetime類型。
getdate()，獲取當前時間的函數。
我覺得你這個語句寫的有問題。第一，參數minute，不需要使用單引號，如果使用了單引號，參數就錯誤了，因為datediff第一個參數不是字元型的。
第二，datediff的函數第二個日期是開始時間，第二個是結束時間，你這個正好反了。
SQL: select * from 日程安排 where datediff(minute,f開始時間，getdate())>5
這個的意思是當前時間已經超過了開始時間5分鍾的，會顯示出來，而不是提前5分鍾提醒。
提前五分鍾提醒：SQL: select * from 日程安排 where datediff(minute,getdate(), f開始時間) < 5
距離當前時間小於5分鍾的記錄，才是提前5分鍾提醒。
2.
select top 10 b.* from (select top 20 主鍵欄位,排序欄位 from 表名 order by 排序欄位 desc) a,表名 b where b.主鍵欄位= a.主鍵欄位 order by a.排序欄位
先看from括弧內的語句：select top 20 主鍵欄位,排序欄位 from 表名 order by 排序欄位 desc，按照排序欄位降序排列取出前20行數據。
然後再整體看，把表和這個20行數據關聯，那麼能取到的最大范圍也就是這20行了。
然後取出前10行，我不知道這個為什麼叫做分頁查詢，因為根本沒有每頁多少行以及第幾頁的參數在。這個語句就是按照排序欄位倒敘排列的前20行，然後在按照排序欄位正序排列從這前20行中取出前10行。實際上就是取出了按照排序欄位倒敘排列的第11-20行的數據並正序排列。
3.內連接：實際上就是兩表直接連接，取出連接成立的所有數據。語法使用Inner join
距離：有學生表：student : student_id , student_name
001 張三
002 李四
003 王五
成績表： score : course_id student_id score
課程1 001 85
課程2 001 85
課程1 002 80
課程2 002 90
查詢學生選課成績，顯示 student_name, course_id, score
select a.student_name, b.course_id, b.score
from student a inner join score b on a.student_id = b.student_id
查詢結果 student_name, course_id, score
張三 課程1 85
張三 課程2 85
李四 課程1 80
李四 課程2 90
可以看到，直接符合連接條件的數據，都會被選擇出來，而王五，因為在成績表沒有成績，所以查詢結果並沒有王五的數據。
4.外連接，left join, right join，分別是左外連接和右外連接。
就是以一個表為主，而另一個表為輔。主表的數據都會被查詢出來，而符合兩表連接條件，那麼輔表的數據就會顯示，否則，為空（NULL）
還以上表和上述語句為例，查詢所有學生的成績清單，沒有成績顯示空，但是學生要顯示。
select a.student_name, b.course_id, b.score
from student a left join score b on a.student_id = b.student_id
查詢結果：
student_name course_id score
張三 課程1 85
張三 課程2 85
李四 課程1 80
李四 課程2 90
王五 NULL NULL
可以看到，雖然連接條件王五這條並不成立，但是王五的數據一樣會被顯示出來，只是成績表的相關數據位空。
有連接和左連接一樣，把上面的順序換過來，效果相同
select a.student_name, b.course_id, b.score
from score b right join student a on a.student_id = b.student_id
⑹ SQLSERVER 語句 求解
select * from [table] t where id=(select top 1 id from [table] where typeid=t.typeid order by newid())
--id是主鍵
⑺ sqlserver 語句（高分懸賞）！關鍵字：asp.net ,datalist！解決好的，追加100分，財富多！
select top 10 ID,case when len(info)>15 then left(info,15)+'...' when len(info)<15 then info end as info from tb_info order by id desc
case ... end 後面那個 as info 一定要加,否則返回的查詢沒有名字叫 info 的列，當然會報錯。
⑻ 如何對變異的sql語句做解析處理
優化SQL查詢：如何寫出高性能SQL語句1、首先要搞明白什麼叫執行計劃？執行計劃是資料庫根據SQL語句和相關表的統計信息作出的一個查詢方案，這個方案是由查詢優化器自動分析產生欀如一條SQL語句如果用來從一個10萬條記錄的表中查1條記錄，那查詢優化器會選擇「索引查找」方式，如果該表進行了歸檔，當前只剩下5000條記錄了，那查詢優化器就會改變方案，採用「全表掃描」方式。可見，執行計劃並不是固定的，它是「個性化的」。產生一個正確的「執行計劃」有兩點很重要：(1)SQL語句是否清晰地告訴查詢優化器它想干什麼？(2)查詢優化器得到的資料庫統計信息是否是最新的、正確的？2、統一SQL語句的寫法對於以下兩句SQL語句，程序員認為是相同的，資料庫查詢優化器認為是不同的。select*fromalselect*Fromal其實就是大小寫不同，查詢分析器就認為是兩句不同的SQL語句，必須進行兩次解析。生成2個執行計劃。所以作為程序員，應該保證相同的查詢語句在任何地方都一致，多一個空格都不行！3、不要把SQL語句寫得太復雜我經常看到，從資料庫中捕捉到的一條SQL語句列印出來有2張A4紙這么長。一般來說這么復雜的語句通常都是有問題的。我拿著這2頁長的SQL語句去請教原作者，結果他說時間太長，他一時也看不懂了。可想而知，連原作者都有可能看糊塗的SQL語句，資料庫也一樣會看糊塗。一般，將一個Select語句的結果作為子集，然後從該子集中再進行查詢，這種一層嵌套語句還是比較常見的，但是根據經驗，超過3層嵌套，查詢優化器就很容易給出錯誤的執行計劃。因為它被繞暈了。像這種類似人工智慧的東西，終究比人的分辨力要差些，如果人都看暈了，我可以保證資料庫也會暈的。另外，執行計劃是可以被重用的，越簡單的SQL語句被重用的可能性越高。而復雜的SQL語句只要有一個字元發生變化就必須重新解析，然後再把這一大堆垃圾塞在內存里。可想而知，資料庫的效率會何等低下。4、使用「臨時表」暫存中間結果簡化SQL語句的重要方法就是採用臨時表暫存中間結果，但是，臨時表的好處遠遠不止這些，將臨時結果暫存在臨時表，後面的查詢就在tempdb中了，這可以避免程序中多次掃描主表，也大大減少了程序執行中「共享鎖」阻塞「更新鎖」，減少了阻塞，提高了並發性能。5、OLTP系統SQL語句必須採用綁定變數select*>』2010-10-2000:00:01′select*>』2010-09-2200:00:01′以上兩句語句，查詢優化器認為是不同的SQL語句，需要解析兩次。如果採用綁定變數select*>@chgtime@chgtime變數可以傳入任何值，這樣大量的類似查詢可以重用該執行計劃了，這可以大大降低資料庫解析SQL語句的負擔。一次解析，多次重用，是提高資料庫效率的原則。6、綁定變數窺測事物都存在兩面性，綁定變數對大多數OLTP處理是適用的，但是也有例外。比如在where條件中的欄位是「傾斜欄位」的時候。「傾斜欄位」指該列中的絕大多數的值都是相同的，一張人口調查表，其中「民族」這列，90%以上都是漢族。那麼如果一個SQL語句要查詢30歲的漢族人口有多少，那「民族」這列必然要被放在where條件中。這個時候如果採用綁定變數@nation會存在很大問題。試想如果@nation傳入的第一個值是「漢族」，那整個執行計劃必然會選擇表掃描。然後，第二個值傳入的是「布依族」，按理說「布依族」占的比例可能只有萬分之一，應該採用索引查找。但是，由於重用了第一次解析的「漢族」的那個執行計劃，那麼第二次也將採用表掃描方式。這個問題就是著名的「綁定變數窺測」，建議對於「傾斜欄位」不要採用綁定變數。7、只在必要的情況下才使用begintranSQLServer中一句SQL語句默認就是一個事務，在該語句執行完成後也是默認commit的。其實，這就是begintran的一個最小化的形式，好比在每句語句開頭隱含了一個begintran，結束時隱含了一個commit。有些情況下，我們需要顯式聲明begintran，比如做「插、刪、改」操作需要同時修改幾個表，要求要麼幾個表都修改成功，要麼都不成功。begintran可以起到這樣的作用，它可以把若干SQL語句套在一起執行，最後再一起commit。好處是保證了數據的一致性，但任何事情都不是完美無缺的。Begintran付出的代價是在提交之前，所有SQL語句鎖住的資源都不能釋放，直到commit掉。可見，如果Begintran套住的SQL語句太多，那資料庫的性能就糟糕了。在該大事務提交之前，必然會阻塞別的語句，造成block很多。Begintran使用的原則是，在保證數據一致性的前提下，begintran套住的SQL語句越少越好！有些情況下可以採用觸發器同步數據，不一定要用begintran。8、一些SQL查詢語句應加上nolock在SQL語句中加nolock是提高SQLServer並發性能的重要手段，在oracle中並不需要這樣做，因為oracle的結構更為合理，有undo表空間保存「數據前影」，該數據如果在修改中還未commit，那麼你讀到的是它修改之前的副本，該副本放在undo表空間中。這樣，oracle的讀、寫可以做到互不影響，這也是oracle廣受稱贊的地方。SQLServer的讀、寫是會相互阻塞的，為了提高並發性能，對於一些查詢，可以加上nolock，這樣讀的時候可以允許寫，但缺點是可能讀到未提交的臟數據。使用nolock有3條原則。(1)查詢的結果用於「插、刪、改」的不能加nolock！(2)查詢的表屬於頻繁發生頁分裂的，慎用nolock！(3)使用臨時表一樣可以保存「數據前影」，起到類似oracle的undo表空間的功能，能採用臨時表提高並發性能的，不要用nolock。9、聚集索引沒有建在表的順序欄位上，該表容易發生頁分裂比如訂單表，有訂單編號orderid，也有客戶編號contactid，那麼聚集索引應該加在哪個欄位上呢？對於該表，訂單編號是順序添加的，如果在orderid上加聚集索引，新增的行都是添加在末尾，這樣不容易經常產生頁分裂。然而，由於大多數查詢都是根據客戶編號來查的，因此，將聚集索引加在contactid上才有意義。而contactid對於訂單表而言，並非順序欄位。比如「張三」的「contactid」是001，那麼「張三」的訂單信息必須都放在這張表的第一個數據頁上，如果今天「張三」新下了一個訂單，那該訂單信息不能放在表的最後一頁，而是第一頁！如果第一頁放滿了呢？很抱歉，該表所有數據都要往後移動為這條記錄騰地方。SQLServer的索引和Oracle的索引是不同的，SQLServer的聚集索引實際上是對表按照聚集索引欄位的順序進行了排序，相當於oracle的索引組織表。SQLServer的聚集索引就是表本身的一種組織形式，所以它的效率是非常高的。也正因為此，插入一條記錄，它的位置不是隨便放的，而是要按照順序放在該放的數據頁，如果那個數據頁沒有空間了，就引起了頁分裂。所以很顯然，聚集索引沒有建在表的順序欄位上，該表容易發生頁分裂。曾經碰到過一個情況，一位哥們的某張表重建索引後，插入的效率大幅下降了。估計情況大概是這樣的。該表的聚集索引可能沒有建在表的順序欄位上，該表經常被歸檔，所以該表的數據是以一種稀疏狀態存在的。比如張三下過20張訂單，而最近3個月的訂單只有5張，歸檔策略是保留3個月數據，那麼張三過去的15張訂單已經被歸檔，留下15個空位，可以在insert發生時重新被利用。在這種情況下由於有空位可以利用，就不會發生頁分裂。但是查詢性能會比較低，因為查詢時必須掃描那些沒有數據的空位。重建聚集索引後情況改變了，因為重建聚集索引就是把表中的數據重新排列一遍，原來的空位沒有了，而頁的填充率又很高，插入數據經常要發生頁分裂，所以性能大幅下降。對於聚集索引沒有建在順序欄位上的表，是否要給與比較低的頁填充率？是否要避免重建聚集索引？是一個值得考慮的問題！10、加nolock後查詢經常發生頁分裂的表，容易產生跳讀或重復讀加nolock後可以在「插、刪、改」的同時進行查詢，但是由於同時發生「插、刪、改」，在某些情況下，一旦該數據頁滿了，那麼頁分裂不可避免，而此時nolock的查詢正在發生，比如在第100頁已經讀過的記錄，可能會因為頁分裂而分到第101頁，這有可能使得nolock查詢在讀101頁時重復讀到該條數據，產生「重復讀」。同理，如果在100頁上的數據還沒被讀到就分到99頁去了，那nolock查詢有可能會漏過該記錄，產生「跳讀」。上面提到的哥們，在加了nolock後一些操作出現報錯，估計有可能因為nolock查詢產生了重復讀，2條相同的記錄去插入別的表，當然會發生主鍵沖突。11、使用like進行模糊查詢時應注意有的時候會需要進行一些模糊查詢比如select*fromcontactwhereusernamelike『%yue%』關鍵詞%yue%，由於yue前面用到了「%」，因此該查詢必然走全表掃描，除非必要，否則不要在關鍵詞前加%，12、數據類型的隱式轉換對查詢效率的影響sqlserver2000的資料庫一的程序在提交sql語句的時候，沒有使用強類型提交這個欄位的值，由sqlserver2000自動轉換數據類型，會導致傳入的參數與主鍵欄位類型不一致，這個時候sqlserver2000可能就會使用全表掃描。Sql2005上沒有發現這種問題，但是還是應該注意一下。13、SQLServer表連接的三種方式(1)MergeJoin(2)NestedLoopJoin(3)HashJoinSQLServer2000隻有一種join方式——NestedLoopJoin，如果A結果集較小，那就默認作為外表，A中每條記錄都要去B中掃描一遍，實際掃過的行數相當於A結果集行數xB結果集行數。所以如果兩個結果集都很大，那Join的結果很糟糕。SQLServer2005新增了MergeJoin，如果A表和B表的連接欄位正好是聚集索引所在欄位，那麼表的順序已經排好，只要兩邊拼上去就行了，這種join的開銷相當於A表的結果集行數加上B表的結果集行數，一個是加，一個是乘，可見mergejoin的效果要比NestedLoopJoin好多了。如果連接的欄位上沒有索引，那SQL2000的效率是相當低的，而SQL2005提供了Hashjoin，相當於臨時給A，B表的結果集加上索引，因此SQL2005的效率比SQL2000有很大提高，我認為，這是一個重要的原因。總結一下，在表連接時要注意以下幾點：(1)連接欄位盡量選擇聚集索引所在的欄位(2)仔細考慮where條件，盡量減小A、B表的結果集(3)如果很多join的連接欄位都缺少索引，而你還在用SQLServer2000，趕緊升級吧。
⑼ SQLServer 資料庫提示「錯誤的語法:"XXXX"必須是批處理中僅有的語句 」報錯的原因分析
一、報錯的原因分析：
批處理必須以CREATE語句開始。也就是一個查詢分析器裡面只有一個批處理語句才是規范的語法。
因為CREATE DEFAULT、CREATE FUNCTION、CREATE PROCEDURE、CREATE RULE、CREATE SCHEMA、CREATE TRIGGER和CREATE VIEW語句不能在批處理中與其他語句組合使用。
所有跟在該批處理後的其他語句將被解釋為第一個CREATE語句定義的一部分。
二、解決方法：
在代碼之間加GO關鍵字分批即可。也可以重新建立一個查詢來寫這個批處理語句。
⑽ sqlserver executionstack怎麼分析
1，victim-list沒什麼可分析的。
2，process-list中關於各個process的詳細信息很重要。
3，再看process中的inputbuf。這個tag表明了process正在運行的語句，因此對於定位死鎖非常重要。但這里有一個問題，比如上例中，inputbuf是一個存儲過程，其中又嵌套了很多其他的存儲過程，而我們需要在其中找出直接導致死鎖的語句並優化，從而解決或減少死鎖。自此我們已經有的信息是：導致死鎖的語句由inputbuf中的語句調用，同時導致死鎖的語句必定是對表MatchService的修改語句。如果存儲過程很簡單，到此DBA已經能夠找到直接導致死鎖的sql了，分析過程到此結束。而如果存儲過程很復雜，則需要進一步分析。
4，現在再進一步考察tag, executionStack。executionStack表明了死鎖發生時，由該process調用的，正在運行的所有sql。上例中有4條sql。同時仔細觀察上例可以發生，兩個process的executionStack是完全相同的，因此考察一個就可以了。另外，如果procname不為空則直接得到了sql，但上例中該tag為空。
我們可能還需要找出包含該sql的具體存儲過程，然後進行優化。出了用sql查詢外，推薦使用一個叫「SQL Search」的第三方工具，很方便，免費的。