技術(shù)文檔 - PostgreSQL 性能優(yōu)化之 fsync 參數(shù)

目 錄

創(chuàng)新互聯(lián)建站主要從事成都網(wǎng)站設(shè)計(jì)、做網(wǎng)站、網(wǎng)頁設(shè)計(jì)、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)彌勒,10年網(wǎng)站建設(shè)經(jīng)驗(yàn),價(jià)格優(yōu)惠、服務(wù)專業(yè),歡迎來電咨詢建站服務(wù):13518219792

總 結(jié)

PostgreSQL 通過調(diào)用系統(tǒng) fsync() 或者其他使得事務(wù)內(nèi)容寫入到物理磁盤，這樣可以保證操作系統(tǒng)或者數(shù)據(jù)庫出現(xiàn)宕機(jī)后，仍然可以恢復(fù)到某一個(gè)一致性的狀態(tài)。理論上講 PostgreSQL 的 fsync 功能關(guān)閉，可以實(shí)現(xiàn)性能的提升，但是帶來的影響就是需要承擔(dān)數(shù)據(jù)的丟失，因?yàn)槌霈F(xiàn)系統(tǒng)宕機(jī)或者數(shù)據(jù)庫崩潰的時(shí)候有一些數(shù)據(jù)是沒有落盤的。

本文將驗(yàn)證 fsync 參數(shù)的性能影響，以及參數(shù)關(guān)閉時(shí)數(shù)據(jù)庫宕機(jī)后的影響。

數(shù)據(jù)量：1000W

fsync 參數(shù)：on

初始化表：user_info

pgbench 壓測

pgbench 結(jié)果

pgbench 壓測

pgbench 結(jié)果

數(shù)據(jù)量：1000W

fsync 參數(shù)：off

初始化表：user_info

pgbench 壓測

pgbench 結(jié)果

pgbench 壓測

pgbench 結(jié)果

通過對比發(fā)現(xiàn)，將 fsync 改為 off，對于讀 TPS，參數(shù) fsync 的影響不大，對于寫 TPS，性能有一定提升。

現(xiàn)在驗(yàn)證參數(shù)關(guān)閉時(shí)數(shù)據(jù)庫宕機(jī)后的影響

首先，使用將數(shù)據(jù)庫性能跑起來

然后，模擬服務(wù)器斷電

之后，啟動數(shù)據(jù)庫

提示信息：比致命錯(cuò)誤還過分的錯(cuò)誤。

結(jié)果：數(shù)據(jù)庫無法啟動，原因就是因?yàn)闊o法找到一個(gè)有效的 checkpoint 記錄，這就是因?yàn)?fsync 設(shè)置為 off，由于數(shù)據(jù)庫異常宕機(jī)導(dǎo)致?？梢酝ㄟ^使用 pg_resetxlog 恢復(fù)數(shù)據(jù)庫，但是會造成部分?jǐn)?shù)據(jù)無法找回，數(shù)據(jù)丟失；也可以通過備份恢復(fù)，同樣也會丟失部分?jǐn)?shù)據(jù)。

fsync 參數(shù)對于讀 TPS 的性能影響不大，對于寫 TPS 的性能有一些影響，設(shè)置為 off，寫 TPS 性能有一定提升，但是存在數(shù)據(jù)庫宕機(jī)后無法正常啟動，即使恢復(fù)后啟動數(shù)據(jù)庫，也會有數(shù)據(jù)丟失的很大風(fēng)險(xiǎn)。因此生產(chǎn)環(huán)境非必要時(shí)，不要將此參數(shù)設(shè)置為 off，還是使用默認(rèn)的 on 比較穩(wěn)妥。

postgres對order by怎么優(yōu)化

select * from (select 除了時(shí)間所有字段寫出來,to_date('COMMENTTIME','yyyy-mm-dd hh24:mi:ss') time from T_SCHOOL_RECORDCOMMENT where RECORDID = :p_cid) order by time desc;

這樣試試，但是你的時(shí)間字段用該保存為date類型，這樣好像很麻煩。。

SQL語句優(yōu)化，使用postgresql數(shù)據(jù)庫，查詢下面sql,需要20多分鐘：

postgresql（8.2）的配置文件中有一個(gè)參數(shù)log_min_duration_statement，意思是只log執(zhí)行時(shí)間大于設(shè)定值的語句，如果設(shè)為0，表示log所有語句；如果設(shè)為-1，表示不log任何語句。

看起來，這個(gè)配置選項(xiàng)對性能的調(diào)整是很有用的，比如可以設(shè)置：

log_min_duration_statement = 1000

則只log執(zhí)行時(shí)間大于1s的語句，重點(diǎn)優(yōu)化這些sql語句就好了。

然而，奇怪的，這個(gè)選項(xiàng)不太容易生效！經(jīng)過反復(fù)試驗(yàn)，原來需要如下配置：

#debug_print_parse = off

#debug_print_rewritten = off

#debug_print_plan = off

#debug_pretty_print = off

log_connections = off

#log_disconnections = off

log_duration = off

log_line_prefix = '%t [%p]: [%l-1] ' # Special values:

# %u = user name

# %d = database name

# %r = remote host and port

# %h = remote host

# %p = PID

# %t = timestamp (no milliseconds)

# %m = timestamp with milliseconds

# %i = command tag

# %c = session id

# %l = session line number

# %s = session start timestamp

# %x = transaction id

# %q = stop here in non-session

# processes

# %% = '%'

# e.g. '%u%%%d '

log_statement = 'none' # none, mod, ddl, all

#log_statement = 'all' # none, mod, ddl, all

#log_hostname = off

注意看上面的其中兩個(gè)選項(xiàng)的設(shè)置：

log_duration = off

log_statement = 'none'

這兩個(gè)選項(xiàng)的意思是不log任何sql語句和執(zhí)行時(shí)間，但是恰恰是關(guān)閉了這兩個(gè)，log_min_duration_statement才會生效！可能postgresql內(nèi)部 對這兩個(gè)選項(xiàng)做了“互斥”處理吧。

PostgreSQL count 做了全表掃描 怎么優(yōu)化

插入有inserted表就是臨時(shí)表刪除deleted表也是臨時(shí)表，當(dāng)執(zhí)行插入或者刪除的時(shí)候可以從中查出相關(guān)數(shù)據(jù)

如何提高postgresql查詢性能

一、使用EXPLAIN：

PostgreSQL為每個(gè)查詢都生成一個(gè)查詢規(guī)劃，因?yàn)檫x擇正確的查詢路徑對性能的影響是極為關(guān)鍵的。PostgreSQL本身已經(jīng)包含了一個(gè)規(guī)劃器用于尋找最優(yōu)規(guī)劃，我們可以通過使用EXPLAIN命令來查看規(guī)劃器為每個(gè)查詢生成的查詢規(guī)劃。

PostgreSQL中生成的查詢規(guī)劃是由1到n個(gè)規(guī)劃節(jié)點(diǎn)構(gòu)成的規(guī)劃樹，其中最底層的節(jié)點(diǎn)為表掃描節(jié)點(diǎn)，用于從數(shù)據(jù)表中返回檢索出的數(shù)據(jù)行。然而，不同

的掃描節(jié)點(diǎn)類型代表著不同的表訪問模式，如：順序掃描、索引掃描，以及位圖索引掃描等。如果查詢?nèi)匀恍枰B接、聚集、排序，或者是對原始行的其它操作，那

么就會在掃描節(jié)點(diǎn)"之上"有其它額外的節(jié)點(diǎn)。并且這些操作通常都有多種方法，因此在這些位置也有可能出現(xiàn)不同的節(jié)點(diǎn)類型。EXPLAIN將為規(guī)劃樹中的每

個(gè)節(jié)點(diǎn)都輸出一行信息，顯示基本的節(jié)點(diǎn)類型和規(guī)劃器為執(zhí)行這個(gè)規(guī)劃節(jié)點(diǎn)計(jì)算出的預(yù)計(jì)開銷值。第一行(最上層的節(jié)點(diǎn))是對該規(guī)劃的總執(zhí)行開銷的預(yù)計(jì)，這個(gè)數(shù)

值就是規(guī)劃器試圖最小化的數(shù)值。

這里有一個(gè)簡單的例子，如下：

復(fù)制代碼 代碼如下:

EXPLAIN SELECT * FROM tenk1;

QUERY PLAN

-------------------------------------------------------------

Seq Scan on tenk1 (cost=0.00..458.00 rows=10000 width=244)

EXPLAIN引用的數(shù)據(jù)是：

1). 預(yù)計(jì)的啟動開銷(在輸出掃描開始之前消耗的時(shí)間，比如在一個(gè)排序節(jié)點(diǎn)里做排續(xù)的時(shí)間)。

2). 預(yù)計(jì)的總開銷。

3). 預(yù)計(jì)的該規(guī)劃節(jié)點(diǎn)輸出的行數(shù)。

4). 預(yù)計(jì)的該規(guī)劃節(jié)點(diǎn)的行平均寬度(單位：字節(jié))。

這里開銷(cost)的計(jì)算單位是磁盤頁面的存取數(shù)量，如1.0將表示一次順序的磁盤頁面讀取。其中上層節(jié)點(diǎn)的開銷將包括其所有子節(jié)點(diǎn)的開銷。這里的輸出

行數(shù)(rows)并不是規(guī)劃節(jié)點(diǎn)處理/掃描的行數(shù)，通常會更少一些。一般而言，頂層的行預(yù)計(jì)數(shù)量會更接近于查詢實(shí)際返回的行數(shù)。

現(xiàn)在我們執(zhí)行下面基于系統(tǒng)表的查詢：

復(fù)制代碼 代碼如下:

SELECT relpages, reltuples FROM pg_class WHERE relname = 'tenk1';

從查詢結(jié)果中可以看出tenk1表占有358個(gè)磁盤頁面和10000條記錄，然而為了計(jì)算cost的值，我們?nèi)匀恍枰懒硗庖粋€(gè)系統(tǒng)參數(shù)值。

復(fù)制代碼 代碼如下:

postgres=# show cpu_tuple_cost;

cpu_tuple_cost

----------------

0.01

(1 row)

cost = 358(磁盤頁面數(shù)) + 10000(行數(shù)) * 0.01(cpu_tuple_cost系統(tǒng)參數(shù)值)

下面我們再來看一個(gè)帶有WHERE條件的查詢規(guī)劃。

復(fù)制代碼 代碼如下:

EXPLAIN SELECT * FROM tenk1 WHERE unique1 7000;

QUERY PLAN

------------------------------------------------------------

Seq Scan on tenk1 (cost=0.00..483.00 rows=7033 width=244)

Filter: (unique1 7000)

EXPLAIN的輸出顯示，WHERE子句被當(dāng)作一個(gè)"filter"應(yīng)用，這表示該規(guī)劃節(jié)點(diǎn)將掃描表中的每一行數(shù)據(jù)，之后再判定它們是否符合過濾的條

件，最后僅輸出通過過濾條件的行數(shù)。這里由于WHERE子句的存在，預(yù)計(jì)的輸出行數(shù)減少了。即便如此，掃描仍將訪問所有10000行數(shù)據(jù)，因此開銷并沒有

真正降低，實(shí)際上它還增加了一些因數(shù)據(jù)過濾而產(chǎn)生的額外CPU開銷。

上面的數(shù)據(jù)只是一個(gè)預(yù)計(jì)數(shù)字，即使是在每次執(zhí)行ANALYZE命令之后也會隨之改變，因?yàn)锳NALYZE生成的統(tǒng)計(jì)數(shù)據(jù)是通過從該表中隨機(jī)抽取的樣本計(jì)算的。

如果我們將上面查詢的條件設(shè)置的更為嚴(yán)格一些的話，將會得到不同的查詢規(guī)劃，如：

復(fù)制代碼 代碼如下:

EXPLAIN SELECT * FROM tenk1 WHERE unique1 100;

QUERY PLAN

------------------------------------------------------------------------------

Bitmap Heap Scan on tenk1 (cost=2.37..232.35 rows=106 width=244)

Recheck Cond: (unique1 100)

- Bitmap Index Scan on tenk1_unique1 (cost=0.00..2.37 rows=106 width=0)

Index Cond: (unique1 100)

這里，規(guī)劃器決定使用兩步規(guī)劃，最內(nèi)層的規(guī)劃節(jié)點(diǎn)訪問一個(gè)索引，找出匹配索引條件的行的位置，然后上層規(guī)劃節(jié)點(diǎn)再從表里讀取這些行。單獨(dú)地讀取數(shù)據(jù)行比順

序地讀取它們的開銷要高很多，但是因?yàn)椴⒎窃L問該表的所有磁盤頁面，因此該方法的開銷仍然比一次順序掃描的開銷要少。這里使用兩層規(guī)劃的原因是因?yàn)樯蠈右?guī)

劃節(jié)點(diǎn)把通過索引檢索出來的行的物理位置先進(jìn)行排序，這樣可以最小化單獨(dú)讀取磁盤頁面的開銷。節(jié)點(diǎn)名稱里面提到的"位圖(bitmap)"是進(jìn)行排序的機(jī)

制。

現(xiàn)在我們還可以將WHERE的條件設(shè)置的更加嚴(yán)格，如：

復(fù)制代碼 代碼如下:

EXPLAIN SELECT * FROM tenk1 WHERE unique1 3;

QUERY PLAN

------------------------------------------------------------------------------

Index Scan using tenk1_unique1 on tenk1 (cost=0.00..10.00 rows=2 width=244)

Index Cond: (unique1 3)

在該SQL中，表的數(shù)據(jù)行是以索引的順序來讀取的，這樣就會令讀取它們的開銷變得更大，然而事實(shí)上這里將要獲取的行數(shù)卻少得可憐，因此沒有必要在基于行的物理位置進(jìn)行排序了。

現(xiàn)在我們需要向WHERE子句增加另外一個(gè)條件，如：

復(fù)制代碼 代碼如下:

EXPLAIN SELECT * FROM tenk1 WHERE unique1 3 AND stringu1 = 'xxx';

QUERY PLAN

------------------------------------------------------------------------------

Index Scan using tenk1_unique1 on tenk1 (cost=0.00..10.01 rows=1 width=244)

Index Cond: (unique1 3)

Filter: (stringu1 = 'xxx'::name)

新增的過濾條件stringu1 = 'xxx'只是減少了預(yù)計(jì)輸出的行數(shù)，但是并沒有減少實(shí)際開銷，因?yàn)槲覀內(nèi)匀恍枰L問相同數(shù)量的數(shù)據(jù)行。而該條件并沒有作為一個(gè)索引條件，而是被當(dāng)成對索引結(jié)果的過濾條件來看待。

如果WHERE條件里有多個(gè)字段存在索引，那么規(guī)劃器可能會使用索引的AND或OR的組合，如：

復(fù)制代碼 代碼如下:

EXPLAIN SELECT * FROM tenk1 WHERE unique1 100 AND unique2 9000;

QUERY PLAN

-------------------------------------------------------------------------------------

Bitmap Heap Scan on tenk1 (cost=11.27..49.11 rows=11 width=244)

Recheck Cond: ((unique1 100) AND (unique2 9000))

- BitmapAnd (cost=11.27..11.27 rows=11 width=0)

- Bitmap Index Scan on tenk1_unique1 (cost=0.00..2.37 rows=106 width=0)

Index Cond: (unique1 100)

- Bitmap Index Scan on tenk1_unique2 (cost=0.00..8.65 rows=1042 width=0)

Index Cond: (unique2 9000)

這樣的結(jié)果將會導(dǎo)致訪問兩個(gè)索引，與只使用一個(gè)索引，而把另外一個(gè)條件只當(dāng)作過濾器相比，這個(gè)方法未必是更優(yōu)。

現(xiàn)在讓我們來看一下基于索引字段進(jìn)行表連接的查詢規(guī)劃，如：

復(fù)制代碼 代碼如下:

EXPLAIN SELECT * FROM tenk1 t1, tenk2 t2 WHERE t1.unique1 100 AND t1.unique2 = t2.unique2;

QUERY PLAN

--------------------------------------------------------------------------------------

Nested Loop (cost=2.37..553.11 rows=106 width=488)

- Bitmap Heap Scan on tenk1 t1 (cost=2.37..232.35 rows=106 width=244)

Recheck Cond: (unique1 100)

- Bitmap Index Scan on tenk1_unique1 (cost=0.00..2.37 rows=106 width=0)

Index Cond: (unique1 100)

- Index Scan using tenk2_unique2 on tenk2 t2 (cost=0.00..3.01 rows=1 width=244)

Index Cond: ("outer".unique2 = t2.unique2)

從查詢規(guī)劃中可以看出(Nested

Loop)該查詢語句使用了嵌套循環(huán)。外層的掃描是一個(gè)位圖索引，因此其開銷與行計(jì)數(shù)和之前查詢的開銷是相同的，這是因?yàn)闂l件unique1

100發(fā)揮了作用。 這個(gè)時(shí)候t1.unique2 =

t2.unique2條件子句還沒有產(chǎn)生什么作用，因此它不會影響外層掃描的行計(jì)數(shù)。然而對于內(nèi)層掃描而言，當(dāng)前外層掃描的數(shù)據(jù)行將被插入到內(nèi)層索引掃描

中，并生成類似的條件t2.unique2 = constant。所以，內(nèi)層掃描將得到和EXPLAIN SELECT * FROM tenk2

WHERE unique2 = 42一樣的計(jì)劃和開銷。最后，以外層掃描的開銷為基礎(chǔ)設(shè)置循環(huán)節(jié)點(diǎn)的開銷，再加上每個(gè)外層行的一個(gè)迭代(這里是 106

* 3.01)，以及連接處理需要的一點(diǎn)點(diǎn)CPU時(shí)間。

如果不想使用嵌套循環(huán)的方式來規(guī)劃上面的查詢，那么我們可以通過執(zhí)行以下系統(tǒng)設(shè)置，以關(guān)閉嵌套循環(huán)，如：

復(fù)制代碼 代碼如下:

SET enable_nestloop = off;

EXPLAIN SELECT * FROM tenk1 t1, tenk2 t2 WHERE t1.unique1 100 AND t1.unique2 = t2.unique2;

QUERY PLAN

------------------------------------------------------------------------------------------

Hash Join (cost=232.61..741.67 rows=106 width=488)

Hash Cond: ("outer".unique2 = "inner".unique2)

- Seq Scan on tenk2 t2 (cost=0.00..458.00 rows=10000 width=244)

- Hash (cost=232.35..232.35 rows=106 width=244)

- Bitmap Heap Scan on tenk1 t1 (cost=2.37..232.35 rows=106 width=244)

Recheck Cond: (unique1 100)

- Bitmap Index Scan on tenk1_unique1 (cost=0.00..2.37 rows=106 width=0)

Index Cond: (unique1 100)

這個(gè)規(guī)劃仍然試圖用同樣的索引掃描從tenk1里面取出符合要求的100行，并把它們存儲在內(nèi)存中的散列(哈希)表里，然后對tenk2做一次全表順序掃

描，并為每一條tenk2中的記錄查詢散列(哈希)表，尋找可能匹配t1.unique2 =

t2.unique2的行。讀取tenk1和建立散列表是此散列聯(lián)接的全部啟動開銷，因?yàn)槲覀冊陂_始讀取tenk2之前不可能獲得任何輸出行。

此外，我們還可以用EXPLAIN ANALYZE命令檢查規(guī)劃器預(yù)估值的準(zhǔn)確性。這個(gè)命令將先執(zhí)行該查詢，然后顯示每個(gè)規(guī)劃節(jié)點(diǎn)內(nèi)實(shí)際運(yùn)行時(shí)間，以及單純EXPLAIN命令顯示的預(yù)計(jì)開銷，如：

復(fù)制代碼 代碼如下:

EXPLAIN ANALYZE SELECT * FROM tenk1 t1, tenk2 t2 WHERE t1.unique1 100 AND t1.unique2 = t2.unique2;

QUERY PLAN

----------------------------------------------------------------------------------------------------------------------------------

Nested Loop (cost=2.37..553.11 rows=106 width=488) (actual time=1.392..12.700 rows=100 loops=1)

- Bitmap Heap Scan on tenk1 t1 (cost=2.37..232.35 rows=106 width=244) (actual time=0.878..2.367 rows=100 loops=1)

Recheck Cond: (unique1 100)

- Bitmap Index Scan on tenk1_unique1 (cost=0.00..2.37

rows=106 width=0) (actual time=0.546..0.546 rows=100 loops=1)

Index Cond: (unique1 100)

- Index Scan using tenk2_unique2 on tenk2 t2

(cost=0.00..3.01 rows=1 width=244) (actual time=0.067..0.078 rows=1

loops=100)

Index Cond: ("outer".unique2 = t2.unique2)

Total runtime: 14.452 ms

注意"actual time"數(shù)值是以真實(shí)時(shí)間的毫秒來計(jì)算的，而"cost"預(yù)估值是以磁盤頁面讀取數(shù)量來計(jì)算的，所以它們很可能是不一致的。然而我們需要關(guān)注的只是兩組數(shù)據(jù)的比值是否一致。

在一些查詢規(guī)劃里，一個(gè)子規(guī)劃節(jié)點(diǎn)很可能會運(yùn)行多次，如之前的嵌套循環(huán)規(guī)劃，內(nèi)層的索引掃描會為每個(gè)外層行執(zhí)行一次。在這種情況下，"loops"將報(bào)告

該節(jié)點(diǎn)執(zhí)行的總次數(shù)，而顯示的實(shí)際時(shí)間和行數(shù)目則是每次執(zhí)行的平均值。這么做的原因是令這些真實(shí)數(shù)值與開銷預(yù)計(jì)顯示的數(shù)值更具可比性。如果想獲得該節(jié)點(diǎn)所

花費(fèi)的時(shí)間總數(shù)，計(jì)算方式是用該值乘以"loops"值。

EXPLAIN ANALYZE顯示的"Total runtime"包括執(zhí)行器啟動和關(guān)閉的時(shí)間，以及結(jié)果行處理的時(shí)間，但是它并不包括分析、重寫或者規(guī)劃的時(shí)間。

如果EXPLAIN命令僅能用于測試環(huán)境，而不能用于真實(shí)環(huán)境，那它就什么用都沒有。比如，在一個(gè)數(shù)據(jù)較少的表上執(zhí)行EXPLAIN，它不能適用于數(shù)量很

多的大表，因?yàn)橐?guī)劃器的開銷計(jì)算不是線性的，因此它很可能對大些或者小些的表選擇不同的規(guī)劃。一個(gè)極端的例子是一個(gè)只占據(jù)一個(gè)磁盤頁面的表，在這樣的表

上，不管它有沒有索引可以使用，你幾乎都總是得到順序掃描規(guī)劃。規(guī)劃器知道不管在任何情況下它都要進(jìn)行一個(gè)磁盤頁面的讀取，所以再增加幾個(gè)磁盤頁面讀取用

以查找索引是毫無意義的。

二、批量數(shù)據(jù)插入：

有以下幾種方法用于優(yōu)化數(shù)據(jù)的批量插入。

1. 關(guān)閉自動提交：

在批量插入數(shù)據(jù)時(shí)，如果每條數(shù)據(jù)都被自動提交，當(dāng)中途出現(xiàn)系統(tǒng)故障時(shí)，不僅不能保障本次批量插入的數(shù)據(jù)一致性，而且由于有多次提交操作的發(fā)生，整個(gè)插入效

率也會受到很大的打擊。解決方法是，關(guān)閉系統(tǒng)的自動提交，并且在插入開始之前，顯示的執(zhí)行begin

transaction命令，在全部插入操作完成之后再執(zhí)行commit命令提交所有的插入操作。

2. 使用COPY：

使用COPY在一條命令里裝載所有記錄，而不是一系列的INSERT命令。COPY命令是為裝載數(shù)量巨大的數(shù)據(jù)行優(yōu)化過的，它不像INSERT命令那樣靈

活，但是在裝載大量數(shù)據(jù)時(shí)，系統(tǒng)開銷也要少很多。因?yàn)镃OPY是單條命令，因此在填充表的時(shí)就沒有必要關(guān)閉自動提交了。

3. 刪除索引：

如果你正在裝載一個(gè)新創(chuàng)建的表，最快的方法是創(chuàng)建表，用COPY批量裝載，然后創(chuàng)建表需要的任何索引。因?yàn)樵谝汛嬖跀?shù)據(jù)的表上創(chuàng)建索引比維護(hù)逐行增加要快。當(dāng)然在缺少索引期間，其它有關(guān)該表的查詢操作的性能將會受到一定的影響，唯一性約束也有可能遭到破壞。

4. 刪除外鍵約束：

和索引一樣，"批量地"檢查外鍵約束比一行行檢查更加高效。因此，我們可以先刪除外鍵約束，裝載數(shù)據(jù)，然后在重建約束。

5. 增大maintenance_work_mem：

在裝載大量數(shù)據(jù)時(shí)，臨時(shí)增大maintenance_work_mem系統(tǒng)變量的值可以改進(jìn)性能。這個(gè)系統(tǒng)參數(shù)可以提高CREATE

INDEX命令和ALTER TABLE ADD FOREIGN KEY命令的執(zhí)行效率，但是它不會對COPY操作本身產(chǎn)生多大的影響。

6. 增大checkpoint_segments：

臨時(shí)增大checkpoint_segments系統(tǒng)變量的值也可以提高大量數(shù)據(jù)裝載的效率。這是因?yàn)樵谙騊ostgreSQL裝載大量數(shù)據(jù)時(shí)，將會導(dǎo)致

檢查點(diǎn)操作(由系統(tǒng)變量checkpoint_timeout聲明)比平時(shí)更加頻繁的發(fā)生。在每次檢查點(diǎn)發(fā)生時(shí)，所有的臟數(shù)據(jù)都必須flush到磁盤上。

通過提高checkpoint_segments變量的值，可以有效的減少檢查點(diǎn)的數(shù)目。

7. 事后運(yùn)行ANALYZE：

在增加或者更新了大量數(shù)據(jù)之后，應(yīng)該立即運(yùn)行ANALYZE命令，這樣可以保證規(guī)劃器得到基于該表的最新數(shù)據(jù)統(tǒng)計(jì)。換句話說，如果沒有統(tǒng)計(jì)數(shù)據(jù)或者統(tǒng)計(jì)數(shù)據(jù)太過陳舊，那么規(guī)劃器很可能會選擇一個(gè)較差的查詢規(guī)劃，從而導(dǎo)致查詢效率過于低下。

新聞名稱：包含postgresql優(yōu)化指南的詞條
文章出自：http://m.rwnh.cn/article24/dsdheje.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供靜態(tài)網(wǎng)站、網(wǎng)站設(shè)計(jì)、軟件開發(fā)、服務(wù)器托管、ChatGPT、動態(tài)網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)