首先，有一句話要認(rèn)識 ： 80%的性能問題由SQL語句引起。
經(jīng)過看 SYBASE 的書，結(jié)合從 MSSQL 遷移過來的系統(tǒng)過程 ，發(fā)現(xiàn)以下幾個問題比較重要：
經(jīng)驗一、where 條件左邊最好不要使用函數(shù)，比如 ★★★★★
select ... where datediff(day,date1,getdate())>;0
這樣即使在 date1 列上建立了索引，也可能不會使用索引，而使用表掃描。
這樣的語句要重新規(guī)劃設(shè)計，保證不使用函數(shù)也能夠?qū)崿F(xiàn)。通過修改，一個系統(tǒng)過程的運行效率提高大約100倍！此外不要使用諸如like '%ab',不能充分利用索引，而要在%前加字符
經(jīng)驗二、兩個比較字段最好使用相同數(shù)據(jù)類型，而不是兼容數(shù)據(jù)類型。比如 int 與 numeric（感覺一般不是太明顯）★★
經(jīng)驗三、復(fù)合索引的非前導(dǎo)列做條件時，基本沒有起到索引的作用。★★★★★
比如 create index idx_tablename_ab on tablename(a,b)
update tablename set c = XX where b>;= XXX and ...
在這個語句中，基本上索引沒有發(fā)揮作用。 導(dǎo)致表掃描引起blocking 甚至運行十幾分鐘后報告失敗。
一定要認(rèn)真檢查 改正措施： 在接口中附加條件
update tablename set c = XX where a = XXX and b>;= XXX
或者建立索引類似于
create index idx_tablename_ba on tablename(b,a)
經(jīng)驗四、 多個大表的關(guān)聯(lián)查詢，如果性能不好，并且其中一個大表中取的數(shù)據(jù)比較少，可以考慮將查詢分兩步執(zhí)行。★★★★
先將一個大表中的少部分?jǐn)?shù)據(jù) select * into #1 from largetable1 where ...
然后再用 #1 去做關(guān)聯(lián)，效果可能會好不少。（前提：生成 #1表應(yīng)該使用比較好的索引，速度比較快）
經(jīng)驗五、 tempdb 的使用。★★★★★
最好多用 select into ，這樣不記日志 ，尤其是有大量數(shù)據(jù)的報表時。雖然寫起來麻煩，但值得。
create table #tmp1 (......)這樣寫性能不好。尤其是大量使用時，容易發(fā)生tempdb 爭用。
經(jīng)驗六、 系統(tǒng)級別的參數(shù)設(shè)置 ★★★★
一定要估計一下，不要使用太多，占用資源 ，太少，發(fā)生性能問題。
連接數(shù)，索引打開個數(shù)、鎖個數(shù) 等、 當(dāng)然 ，內(nèi)存配置不要有明顯的問題，比如，procedure cache
不夠 （一般缺省20%，如果覺得太多，可以減少一些）。如果做報表經(jīng)常使用大數(shù)據(jù)量讀，可以考慮使用
16Kdata cache
經(jīng)驗七、索引的建立。很重要。★★★★★
clustered index /nonclustered index 的差異，自己要搞清楚。各適用場合，另外如果
clustered index 不允許 重復(fù)數(shù)，也一定要說明。
索引設(shè)計是以為數(shù)據(jù)訪問快速為原則的，不能 完全（！！） 參照數(shù)據(jù)邏輯設(shè)計的，邏輯設(shè)計時的一些東西，
可能對物理訪問不起作用
經(jīng)驗八、統(tǒng)計數(shù)據(jù)的更新：大約10天進(jìn)行 update statistics ,sp_recompile table_name（★★★）
經(jīng)驗九、強(qiáng)制索引使用 （★★★★）
如果懷疑有表訪問時不是使用索引，而且這些條件字段上建立了合適的索引,可以強(qiáng)制使用
select * from tableA (index idx_name) where ...
這個對一些報表程序可能比較有用。
經(jīng)驗十、找一個好的監(jiān)視工具 ★★★
工欲善其事，比先利其器，一點都不錯呀。
我用 DBartisian 5.4 ,監(jiān)視哪些表被鎖定時間長， blocking 等
還有 sp_object_status 20:00:00 ， sp_sysmon 20:00:00 等
以上是我的一點經(jīng)驗，在不到一個月的時間內(nèi)，我修改了20個左右的語句和系統(tǒng)過程 ，
系統(tǒng)性能明顯改善，cpu利用 高峰時大約50% 平時 不到30%IO 明顯改善。所有月報表能順利完成 5min 以內(nèi)。
經(jīng)驗十一： 綜合以上對IN/EXISTS的討論，我們可以得出一個基本通用的結(jié)論：IN適合于外表大而內(nèi)表小的情況；EXISTS適合于外表小而內(nèi)表大的情況。
另外，系統(tǒng)中確認(rèn)不使用的中間數(shù)據(jù)，可以進(jìn)行轉(zhuǎn)移。這些要看系統(tǒng)的情況哦
最后祝你好運氣。
以上為個人經(jīng)驗，歡迎批評指正！
呵呵 寫完后忘記一個 一定要注意熱點表 ，這是影響并發(fā)問題的一個潛在因素。！解決方法： 行鎖模式 如果表的行比較小，可以故意增加一些不用的字段
比如 char(200) 讓一頁中存放的行不要太多。