❶ 做了兩年的java軟體開發，每天都是寫代碼，寫sql寫存儲過程！感覺沒有方向，求高手給個發展方向！謝謝…
由前往後發展，你回成為很牛的分析師，數據管理員，數據挖掘工程師，架構管理師等等的，你可以往深度的地方發展下，就比如說你天天寫過程，有沒有想過操作集群的大數據呢?有沒有想過怎麼去管理數據呢？你說你寫代碼，有沒有想過怎麼架設一個省級的工程架構呢？有沒有想過架構如何做最優化呢？因為你代碼的初期不也是架構么，是吧，你想想自己的代碼能否帶入架構裡面呢。你天天用，就得要往高層一點去管理自己用的東西，這樣才能有質的提升。
❷ 大家幫我寫個SQL語句
declare @num int
select @num= count(CHG_DT) from 表名where (month(CHG_DT)-month(getDate()))<=3
if @num>0 print 'true'
if @num=0 print 'flase'
這個我測試過了，是可以的
這個是在針對伺服器上的時間（也只能以伺服器時間）來判定的，不是以你所操作的電腦的時候為准(如果你所執行這條語句的電腦不是伺服器的話)
樓上的，不知道不要亂說
month()函數你取到的值可能是其他類型的嗎？
❸ 用SQL語句往gridview里添加數據，日期型的數據不填總是報錯，但是資料庫里這一列不是必填項，為什麼
應該是 你 插入資料庫時， 插入的 日期 的類型 和 資料庫設計時的 類型 不 統一。
比如說 ：資料庫中 屬性 日期 的 類型是 datetime 而 你 寫的 sql 語句 時 插入的是 string 類型 就會出現這種錯誤。
❹ 書寫SQL語句
select c_name, c_stu from class where（select c_stu from class where c_stu>50 or c_stu<20）
試試這個
❺ 每天向sql2005資料庫里添加記錄的作業命令怎麼寫
建議你用圖像界面操作：
SQL Server 代理，選擇作業，添加作業，選擇你想要執行的時間，腳本；
然後如果你想把作業生成腳本，可以選中你剛剛添加的作業右鍵編寫作業腳本到 Create 就可以了
❻ 如何寫出高性能SQL語句
1、 首先要搞明白什麼叫執行計劃？
執行計劃是資料庫根據SQL語句和相關表的統計信息作出的一個查詢方案，這個方案是由查詢優化器自動分析產生的，比如一條SQL語句如果用來從一個 10萬條記錄的表中查1條記錄，那查詢優化器會選擇「索引查找」方式，如果該表進行了歸檔，當前只剩下5000條記錄了，那查詢優化器就會改變方案，採用 「全表掃描」方式。
可見，執行計劃並不是固定的，它是「個性化的」。產生一個正確的「執行計劃」有兩點很重要：
(1) SQL語句是否清晰地告訴查詢優化器它想干什麼？
(2) 查詢優化器得到的資料庫統計信息是否是最新的、正確的？
2、 統一SQL語句的寫法
對於以下兩句SQL語句，程序員認為是相同的，資料庫查詢優化器認為是不同的。
select*from al
select*From al
其實就是大小寫不同，查詢分析器就認為是兩句不同的SQL語句，必須進行兩次解析。生成2個執行計劃。所以作為程序員，應該保證相同的查詢語句在任何地方都一致，多一個空格都不行！
3、 不要把SQL語句寫得太復雜
我經常看到，從資料庫中捕捉到的一條SQL語句列印出來有2張A4紙這么長。一般來說這么復雜的語句通常都是有問題的。我拿著這2頁長的SQL語句去請教原作者，結果他說時間太長，他一時也看不懂了。可想而知，連原作者都有可能看糊塗的SQL語句，資料庫也一樣會看糊塗。
一般，將一個Select語句的結果作為子集，然後從該子集中再進行查詢，這種一層嵌套語句還是比較常見的，但是根據經驗，超過3層嵌套，查詢優化器就很容易給出錯誤的執行計劃。因為它被繞暈了。像這種類似人工智慧的東西，終究比人的分辨力要差些，如果人都看暈了，我可以保證資料庫也會暈的。
另外，執行計劃是可以被重用的，越簡單的SQL語句被重用的可能性越高。而復雜的SQL語句只要有一個字元發生變化就必須重新解析，然後再把這一大堆垃圾塞在內存里。可想而知，資料庫的效率會何等低下。
4、 使用「臨時表」暫存中間結果
簡化SQL語句的重要方法就是採用臨時表暫存中間結果，但是，臨時表的好處遠遠不止這些，將臨時結果暫存在臨時表，後面的查詢就在tempdb中了，這可以避免程序中多次掃描主表，也大大減少了程序執行中「共享鎖」阻塞「更新鎖」，減少了阻塞，提高了並發性能。
5、 OLTP系統SQL語句必須採用綁定變數
select*from orderheader where changetime >'2010-10-20 00:00:01'
select*from orderheader where changetime >'2010-09-22 00:00:01'
以上兩句語句，查詢優化器認為是不同的SQL語句，需要解析兩次。如果採用綁定變數
select*from orderheader where changetime >@chgtime
@chgtime變數可以傳入任何值，這樣大量的類似查詢可以重用該執行計劃了，這可以大大降低資料庫解析SQL語句的負擔。一次解析，多次重用，是提高資料庫效率的原則。
6、 綁定變數窺測
事物都存在兩面性，綁定變數對大多數OLTP處理是適用的，但是也有例外。比如在where條件中的欄位是「傾斜欄位」的時候。
「傾斜欄位」指該列中的絕大多數的值都是相同的，比如一張人口調查表，其中「民族」這列，90%以上都是漢族。那麼如果一個SQL語句要查詢30歲的漢族人口有多少，那「民族」這列必然要被放在where條件中。這個時候如果採用綁定變數@nation會存在很大問題。
試想如果@nation傳入的第一個值是「漢族」，那整個執行計劃必然會選擇表掃描。然後，第二個值傳入的是「布依族」，按理說「布依族」占的比例可能只有萬分之一，應該採用索引查找。但是，由於重用了第一次解析的「漢族」的那個執行計劃，那麼第二次也將採用表掃描方式。這個問題就是著名的「綁定變數窺測」，建議對於「傾斜欄位」不要採用綁定變數。
7、 只在必要的情況下才使用begin tran
SQL Server中一句SQL語句默認就是一個事務，在該語句執行完成後也是默認commit的。其實，這就是begin tran的一個最小化的形式，好比在每句語句開頭隱含了一個begin tran，結束時隱含了一個commit。
有些情況下，我們需要顯式聲明begin tran，比如做「插、刪、改」操作需要同時修改幾個表，要求要麼幾個表都修改成功，要麼都不成功。begin tran 可以起到這樣的作用，它可以把若干SQL語句套在一起執行，最後再一起commit。好處是保證了數據的一致性，但任何事情都不是完美無缺的。Begin tran付出的代價是在提交之前，所有SQL語句鎖住的資源都不能釋放，直到commit掉。
可見，如果Begin tran套住的SQL語句太多，那資料庫的性能就糟糕了。在該大事務提交之前，必然會阻塞別的語句，造成block很多。
Begin tran使用的原則是，在保證數據一致性的前提下，begin tran 套住的SQL語句越少越好！有些情況下可以採用觸發器同步數據，不一定要用begin tran。
8、 一些SQL查詢語句應加上nolock
在SQL語句中加nolock是提高SQL Server並發性能的重要手段，在oracle中並不需要這樣做，因為oracle的結構更為合理，有undo表空間保存「數據前影」，該數據如果在修改中還未commit，那麼你讀到的是它修改之前的副本，該副本放在undo表空間中。這樣，oracle的讀、寫可以做到互不影響，這也是oracle 廣受稱贊的地方。SQL Server 的讀、寫是會相互阻塞的，為了提高並發性能，對於一些查詢，可以加上nolock，這樣讀的時候可以允許寫，但缺點是可能讀到未提交的臟數據。使用 nolock有3條原則。
(1) 查詢的結果用於「插、刪、改」的不能加nolock ！
(2) 查詢的表屬於頻繁發生頁分裂的，慎用nolock ！
(3) 使用臨時表一樣可以保存「數據前影」，起到類似oracle的undo表空間的功能，
能採用臨時表提高並發性能的，不要用nolock 。
9、 聚集索引沒有建在表的順序欄位上，該表容易發生頁分裂
比如訂單表，有訂單編號orderid，也有客戶編號contactid，那麼聚集索引應該加在哪個欄位上呢？對於該表，訂單編號是順序添加的，如果在orderid上加聚集索引，新增的行都是添加在末尾，這樣不容易經常產生頁分裂。然而，由於大多數查詢都是根據客戶編號來查的，因此，將聚集索引加在contactid上才有意義。而contactid對於訂單表而言，並非順序欄位。
比如「張三」的「contactid」是001，那麼「張三」的訂單信息必須都放在這張表的第一個數據頁上，如果今天「張三」新下了一個訂單，那該訂單信息不能放在表的最後一頁，而是第一頁！如果第一頁放滿了呢？很抱歉，該表所有數據都要往後移動為這條記錄騰地方。
SQL Server的索引和Oracle的索引是不同的，SQL Server的聚集索引實際上是對表按照聚集索引欄位的順序進行了排序，相當於oracle的索引組織表。SQL Server的聚集索引就是表本身的一種組織形式，所以它的效率是非常高的。也正因為此，插入一條記錄，它的位置不是隨便放的，而是要按照順序放在該放的數據頁，如果那個數據頁沒有空間了，就引起了頁分裂。所以很顯然，聚集索引沒有建在表的順序欄位上，該表容易發生頁分裂。
曾經碰到過一個情況，一位哥們的某張表重建索引後，插入的效率大幅下降了。估計情況大概是這樣的。該表的聚集索引可能沒有建在表的順序欄位上，該表經常被歸檔，所以該表的數據是以一種稀疏狀態存在的。比如張三下過20張訂單，而最近3個月的訂單只有5張，歸檔策略是保留3個月數據，那麼張三過去的 15張訂單已經被歸檔，留下15個空位，可以在insert發生時重新被利用。在這種情況下由於有空位可以利用，就不會發生頁分裂。但是查詢性能會比較低，因為查詢時必須掃描那些沒有數據的空位。
重建聚集索引後情況改變了，因為重建聚集索引就是把表中的數據重新排列一遍，原來的空位沒有了，而頁的填充率又很高，插入數據經常要發生頁分裂，所以性能大幅下降。
對於聚集索引沒有建在順序欄位上的表，是否要給與比較低的頁填充率？是否要避免重建聚集索引？是一個值得考慮的問題！
10、加nolock後查詢經常發生頁分裂的表，容易產生跳讀或重復讀
加nolock後可以在「插、刪、改」的同時進行查詢，但是由於同時發生「插、刪、改」，在某些情況下，一旦該數據頁滿了，那麼頁分裂不可避免，而此時nolock的查詢正在發生，比如在第100頁已經讀過的記錄，可能會因為頁分裂而分到第101頁，這有可能使得nolock查詢在讀101頁時重復讀到該條數據，產生「重復讀」。同理，如果在100頁上的數據還沒被讀到就分到99頁去了，那nolock查詢有可能會漏過該記錄，產生「跳讀」。
上面提到的哥們，在加了nolock後一些操作出現報錯，估計有可能因為nolock查詢產生了重復讀，2條相同的記錄去插入別的表，當然會發生主鍵沖突。
11、使用like進行模糊查詢時應注意
有的時候會需要進行一些模糊查詢比如
select*from contact where username like 『%yue%』
關鍵詞%yue%，由於yue前面用到了「%」，因此該查詢必然走全表掃描，除非必要，否則不要在關鍵詞前加%，
12、數據類型的隱式轉換對查詢效率的影響
sql server2000的資料庫，我們的程序在提交sql語句的時候，沒有使用強類型提交這個欄位的值，由sql server 2000自動轉換數據類型，會導致傳入的參數與主鍵欄位類型不一致，這個時候sql server 2000可能就會使用全表掃描。Sql2005上沒有發現這種問題，但是還是應該注意一下。
13、SQL Server 表連接的三種方式
(1) Merge Join
(2) Nested Loop Join
(3) Hash Join
SQL Server 2000隻有一種join方式——Nested Loop Join，如果A結果集較小，那就默認作為外表，A中每條記錄都要去B中掃描一遍，實際掃過的行數相當於A結果集行數x B結果集行數。所以如果兩個結果集都很大，那Join的結果很糟糕。
SQL Server 2005新增了Merge Join，如果A表和B表的連接欄位正好是聚集索引所在欄位，那麼表的順序已經排好，只要兩邊拼上去就行了，這種join的開銷相當於A表的結果集行數加上B表的結果集行數，一個是加，一個是乘，可見merge join 的效果要比Nested Loop Join好多了。
如果連接的欄位上沒有索引，那SQL2000的效率是相當低的，而SQL2005提供了Hash join，相當於臨時給A，B表的結果集加上索引，因此SQL2005的效率比SQL2000有很大提高，我認為，這是一個重要的原因。
總結一下，在表連接時要注意以下幾點：
(1) 連接欄位盡量選擇聚集索引所在的欄位
(2) 仔細考慮where條件，盡量減小A、B表的結果集
(3) 如果很多join的連接欄位都缺少索引，而你還在用SQL Server 2000，趕緊升級吧。
❼ 如何讓sql每天執行一下一個寫好的sql語句
可以設置定時任務，比較常用的是用sqlserver 代理新建作業。有時候資料庫自動備份也是用的這個。
還有一種比較復雜自己寫個程序，使用系統定時任務 定時執行。
創建sql server定時任務作業步驟如下：
1.要先安裝了sqlserver 代理服務
--2.滑鼠右擊【SQL Server 代理】，選擇【啟動(S)】，如已啟動，可以省略此步驟；
--3.展開【SQL Server 代理】列表，右擊【作業】--【新建作業】；
--3.1 在【常規】選項卡中：
-- 輸入作業名稱，如My Job；
--3.2 在【步驟】選項卡中：
--3.2.1 點擊【新建】，輸入【步驟名稱】，如步驟1，類型默認T-SQL腳本，也可以選擇SSIS包等；
--3.2.2 在【資料庫】一欄選擇要作業處理的資料庫，在【命令】的右邊空白編輯欄輸入要執行的SQL代碼，
EXEC p_Name --如：執行一個P_Name的存儲過程
-- 也可以點擊命令下面的【打開】，打開.sql腳本；
--3.2.3 輸入運行腳本後，建議點擊【分析】，確保腳本語法正確，然後點擊下面的【確定】按鈕；
--3.3 在【計劃】選項卡中：
--3.3.1 點擊【新建】，輸入【計劃名稱】，如計劃1，計劃類型默認是重復執行，也可以選擇執行一次等;
--3.3.2 在【頻率】--【執行】處選擇每天、每周或每月，以每天為例，間隔時間輸入間隔幾天執行一次，
-- 下面還可以選擇每天一次性執行或間隔一定的時間重復執行
--3.3.3 在【持續時間】中選擇計劃開始執行的【起始日期】和【截止日期】，然後點擊【確定】按鈕；
--注意要將服務設置為自動啟動,否則在重啟伺服器後作業就不運行了。
--啟動代理服務的方法：
--開始--運行--輸入services.msc--找到【SQL Server 代理】的服務並雙擊--【啟動類型】選擇自動--【確定】
--至此，定時作業已創建完畢。