最近完成了幾個比較大的數(shù)據(jù)庫優(yōu)化項目，發(fā)現(xiàn)了一些常見的問題，寫出來供大家參考。

這些項目都是遠(yuǎn)程完成的，遠(yuǎn)程收集信息（使用ora工具），遠(yuǎn)程分析，最后在騰訊會議上匯報（也相當(dāng)于實訓(xùn)課）。

其中一個項目，我不敢接受。這也是迄今為止唯一被拒絕的項目。為什么？

現(xiàn)場工程師給我發(fā)了一些收集到的性能信息。雖然系統(tǒng)運行在一體機（較早的版本）上，但SQL的執(zhí)行效率還是很不理想。還制作了數(shù)百 GB 的大型表。分區(qū)，但大多數(shù)不使用分區(qū)字段上的條件，仍然需要全表掃描；

客戶的期望是通過一次操作就能快速看到明顯的優(yōu)化效果，這實在是不可能的。我可以對這個系統(tǒng)提出一些優(yōu)化建議，但是由于設(shè)計原因，需要做很多。短期內(nèi)無法看到效果。涉及到開發(fā)者的配合和大的改動，這個時間是無法控制的。

給 DBA 的一些建議：

在很多情況下，只有系統(tǒng)掛起會引起dba的注意，而大部分系統(tǒng)掛起是由性能問題引起的。 DBA可能會重啟數(shù)據(jù)庫來暫時解決問題，但如果性能問題不能從根本上解決，這種情況還是會經(jīng)常出現(xiàn)，而且頻率會越來越高。

不要亂改參數(shù)

很多百度的DBA都來過一些“專家”的建議，希望通過修改參數(shù)來達(dá)到優(yōu)化的目的，其實可能適得其反。以下是一些“專家”建議修改的參數(shù)：

編輯

mup

ds

_adj

......

我的參數(shù)設(shè)置原則是：

將大部分參數(shù)保留為默認(rèn)值。對于bug，影響的特殊SQL很少，可以在SQL級別單獨處理（提示或）；只有影響比較大的參數(shù)才在級別上進(jìn)行全局調(diào)整。

（很多開發(fā)者也期望有神奇的參數(shù)來達(dá)到優(yōu)化效果，可惜沒有）

2.關(guān)于統(tǒng)計收集

由于某些原因，某些數(shù)據(jù)庫的自動統(tǒng)計信息收集已關(guān)閉。

會自動執(zhí)行一項任務(wù)來收集統(tǒng)計信息。建議開啟這個自動任務(wù)，否則可能會時不時的因為SQL執(zhí)行計劃的惡化而導(dǎo)致性能問題。

統(tǒng)計信息是優(yōu)化器為SQL生成正確執(zhí)行計劃的最重要依據(jù)。如果統(tǒng)計信息不準(zhǔn)確，那么生成的執(zhí)行計劃很可能是次優(yōu)的。

一些高級DBA使用自己的腳本進(jìn)行采集，不推薦； DBA可以根據(jù)業(yè)務(wù)特點，在默認(rèn)采集任務(wù)的基礎(chǔ)上進(jìn)行微調(diào)，如調(diào)整時間窗口，與業(yè)務(wù)錯開；分區(qū)表的增量收集；并行大表集合；并發(fā)收集；調(diào)整默認(rèn)陳舊率（默認(rèn)10%）；調(diào)整采樣率；鎖定歸檔歷史表統(tǒng)計；大分區(qū)表復(fù)制/設(shè)置統(tǒng)計等方法。

關(guān)于手動收集統(tǒng)計數(shù)據(jù)：

執(zhí)行計劃變差時手動統(tǒng)計的幾個重要知識點（包括開發(fā)者在程序代碼中調(diào)用命令統(tǒng)計）：

使用.，不要使用table來收集統(tǒng)計數(shù)據(jù)，因為：

該命令在很久以前沒有命令的時候使用過，還可以收集統(tǒng)計信息（有了之后主要用來做和列出行），命令寫起來比較簡單，但是有比較大的缺陷；

p>

可能因為mysql數(shù)據(jù)庫使用這個命令來收集表的統(tǒng)計信息，也會誤導(dǎo)一些人在數(shù)據(jù)庫上使用這個命令。

.table和table有什么區(qū)別，大家可以自己對比一下，印象深刻。

有些人覺得它很有用。統(tǒng)計后，執(zhí)行計劃并沒有立即改變。這是因為沒有使用 =>false 參數(shù)。這個參數(shù)，只有有經(jīng)驗的dba才知道。

最后給 DBA 一點額外建議：

給予開發(fā)者合理的權(quán)限來收集性能信息，例如生成awr、查看數(shù)據(jù)字典等

給數(shù)據(jù)庫開發(fā)者的幾點建議：

數(shù)據(jù)庫性能問題，90%以上（我個人經(jīng)驗值）都是開發(fā)設(shè)計問題，這里有幾個常見的：

基本上大部分業(yè)務(wù)端不做負(fù)載控制（并發(fā)控制）

sql執(zhí)行時間長的時候，很多很久沒有發(fā)布，新的業(yè)務(wù)請求還在增加，系統(tǒng)不堪重負(fù)，所以掛了。

中間件需要充當(dāng)門。不要以為數(shù)據(jù)庫可以響應(yīng)所有請求。數(shù)據(jù)庫的負(fù)載是有限的，超過限制負(fù)載就會出現(xiàn)問題。達(dá)到一定閾值后，不再添加新請求。 （有時候雖然應(yīng)用端沒有新的請求，但還是無法避免數(shù)據(jù)庫本身的定時任務(wù)）

2.不合理使用綁定變量

這導(dǎo)致大量的硬SQL解析，超過95%的開發(fā)者不知道綁定變量的寫法是什么；這個百度，很簡單，只知道你不知道的關(guān)系。

如果一開始沒有這個概念，如果在系統(tǒng)啟動前或者已經(jīng)啟動之前測試過，然后發(fā)現(xiàn)問題，就更難改系統(tǒng)了。

對于mysql/pg等其他數(shù)據(jù)庫，如果不使用綁定變量，問題可能沒那么嚴(yán)重，但是對于其他數(shù)據(jù)庫，會帶來很多問題，比如并發(fā)不增加，ora-4031，系統(tǒng)越來越慢（緩存被池占用），不容易被發(fā)現(xiàn)。

3.使用模糊查詢作為大表的主要過濾條件

如instt(,'xxx')>0之類的'%xxxxx%'，這個一般需要全表掃描，隨著記錄數(shù)的增加會越來越慢；雖然可以改寫，但是使用索引快速全掃描在改進(jìn)上也有限；最好調(diào)整一下業(yè)務(wù)需求oracle數(shù)據(jù)庫優(yōu)化方法，可以改成‘xxxxx%’之類的最好（去掉一個百分號，最好去掉第一個，最后一個也可以，但是需要做一些特殊處理）。

4.sql編寫和業(yè)務(wù)邏輯實現(xiàn)：

不推薦對大型結(jié)果集進(jìn)行分頁查詢，不推薦使用分頁查詢邏輯的數(shù)據(jù)導(dǎo)出。分頁應(yīng)該盡量減少結(jié)果集； 應(yīng)該一次性導(dǎo)出；

大型結(jié)果集使用標(biāo)量子查詢，執(zhí)行時間會很長，并行性無濟于事。有的需要改成外部關(guān)聯(lián)，有的可能需要借助物化視圖（比如一些報表）來刷新；

......

5.plsql結(jié)合上下文寫優(yōu)化：

如果不看plsql代碼的上下文，單條sql是沒有問題的。以下是幾個例子：

5.1 兩步可以合并為一步，比較簡單

原文拼寫：+兩步：

來自 rp

在哪里 rp。 = :b1 和 rp。 = :b2;

變成(,,,)

(:b3, :b2, :b1);

改進(jìn)寫法，直接一步（表中其他字段設(shè)置為null）：

設(shè)置 =:b3

, =null,=null,....

其中 =:b2 和 = :b1;

5.2 兩個步驟可以合二為一，比較簡單

原始拼寫，先，然后：

進(jìn)入（aaa, bbb, ... 備忘錄）

* 來自 ;

na 設(shè)置 na.aaa = 29010 其中 na.bbb = '111';

na 設(shè)置 na.aaa = 29011 其中 na.bbb = '222';

na 設(shè)置 na.aaa = 29012 其中 na.bbb = '333';

改進(jìn)寫法，只需一次，不需要：

進(jìn)入（aaa, bbb, ... 備忘錄）

(bbb,'111',29010,'222',29011,'333',29012,aaa) ,bbb, .....,memo From ;

5.3 存儲過程調(diào)用函數(shù)實現(xiàn)的邏輯其實可以用簡單的SQL來實現(xiàn)：

--（在SQL不使用綁定變量的情況下，可以加一個=1的條件）：

(clob) 是

;

v_sql(3000);

開始

v_sql := 'count(id)

來自 tf

id in (' || || ')';

v_sql

進(jìn)入;

如果 > 0 那么

1;

其他

0;

如果結(jié)束；

結(jié)束;

/

--存儲過程，調(diào)用上述函數(shù)計算兩個值：

（出，出）

是

:= 0;

開始

count(pid) into from tp;

for x in (pid,(fid) fids from tp group by pid) loop

如果 (x.fids) = 1 那么

:= + 1;

如果結(jié)束；

結(jié)束循環(huán)；

:= ;

結(jié)束；

/

SQL怎么寫oracle數(shù)據(jù)庫優(yōu)化方法，你可以試試，不難。

注意：以上SQL都是從客戶的業(yè)務(wù)代碼中脫敏和簡化的。

以上觀點僅為個人觀點，如有不當(dāng)之處歡迎批評指正。

（全文）