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

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

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

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

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

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

問題是：為什么不早點(diǎn)構(gòu)建這個(gè)索引?

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

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

鑒于SQL性能分析是一項(xiàng)為人所熟知的流程，那么開發(fā)人員為什么不自己進(jìn)行SQL調(diào)優(yōu)呢?難道他們?nèi)狈ο鄳?yīng)工具和知識嗎?

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

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

•添加索引;

•保持RunStats工具版本最新;

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

•采用良好的SQL編碼實(shí)踐;

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

•每一個(gè)方法都可以追溯到多個(gè)問題癥結(jié)。