噜噜噜综合,又色又爽又高潮免费观看,综合无码一区二区三区四区五区,中文字幕无码人妻aaa片,四虎成人精品永久网站

DBA們應該將自己從“我要對什么調優(yōu)?”的老路上解放出來，而在指標、配置和成本方面花費一定的時間。研究這些測量指標并做一個對根本原因的分析，而這將花費很多時間和精力。DBA都是聰明人，但很少在操作系統(tǒng)和DBMS系統(tǒng)性能調優(yōu)上有發(fā)言權。

所以那個曾經(jīng)需要花費10分鐘 CPU時間的查詢，在進行過調優(yōu)之后，現(xiàn)在只需要幾秒鐘，這又如何呢?我們來考慮一些現(xiàn)實的例子。

假設DB2的配置參數(shù)SRTPOOL(排序池大小)設置太低�？赡艿慕Y果就是SQL語句在請求排序 (即通過GROUP BY)時會因為排序池空間不足而出錯。所以DBA告訴開發(fā)人員應該將ORDER BY從他們的查詢中移除，然而自己對返回的結果進行排序來對查詢進行“調優(yōu)”。這算是調優(yōu)么?

還有DBA發(fā)現(xiàn)一個查詢要運行長達兩小時，并且會消耗15分鐘的CPU時間。接著DBA就對查詢做了調優(yōu)，現(xiàn)在它在10分鐘的運行時間里占用10分鐘的CUP時間。這么做有意義嗎?那個查詢原來只消耗12.5%的CPU，但是現(xiàn)在卻要消耗100%的CPU。在任何時候只要一運行這個查詢，CPU占用率就會飆升，從而導致?lián)p失。這又算是什么調優(yōu)呢?

這里有另外一個例子。DBA確信在一個特定表的字段上添加索引會對某條性能不佳的SQL語句提速。所以就添加了索引。

問題是：為什么不早點構建這個索引?

難道是之前的數(shù)據(jù)庫設計流程有誤?如果是這樣，那么DBA們可能就需要在數(shù)據(jù)建模上花費更多的時間了。

難道是新應用程序的業(yè)務邏輯太過模糊，以至于SQL無法在早期階段獲知這種情況?這便指出了應用程序設計流程上存在的問題。

鑒于SQL性能分析是一項為人所熟知的流程，那么開發(fā)人員為什么不自己進行SQL調優(yōu)呢?難道他們缺乏相應工具和知識嗎?

關鍵在于DBA必須調查造成性能不佳的根本原因，而非簡單的定位單條SQL語句。否則，他們將會在以后的職業(yè)生涯里疲于應付SQL調優(yōu)。對于DBA來說，將時間精力花費在SQL調優(yōu)上是否值得呢?通過優(yōu)化應用程序設計和數(shù)據(jù)庫設計流程，讓80%的索引從一開始就得以確定，這種方法豈不是更好?

有幾個方法可供DBA用來做為簡單SQL調優(yōu)：

•添加索引;

•保持RunStats工具版本最新;

•確保數(shù)據(jù)以聚集序列進行加載和存儲;

•采用良好的SQL編碼實踐;

•讓開發(fā)人員做EXPLAIN。

•每一個方法都可以追溯到多個問題癥結。