PostgreSQL數(shù)據(jù)庫(kù)性能調(diào)優(yōu)的注意點(diǎn)以及pg數(shù)據(jù)庫(kù)性能優(yōu)化方式
PostgreSQL 優(yōu)化思路
優(yōu)化思路:
0、為每個(gè)表執(zhí)行 ANALYZE
然后分析 EXPLAIN (ANALYZE,BUFFERS) sql。
1、對(duì)于多表查詢,查看每張表數(shù)據(jù),然后改進(jìn)連接順序。
2、先查找那部分是重點(diǎn)語(yǔ)句,比如上面SQL,外面的嵌套層對(duì)于優(yōu)化來(lái)說(shuō)沒(méi)有意義,可以去掉。
3、查看語(yǔ)句中,where等條件子句,每個(gè)字段能過(guò)濾的效率。找出可優(yōu)化處。
比如oc.order_id = oo.order_id是關(guān)聯(lián)條件,需要加索引
- oc.op_type = 3 能過(guò)濾出1/20的數(shù)據(jù),
- oo.event_type IN (…) 能過(guò)濾出1/10的數(shù)據(jù),
這兩個(gè)是優(yōu)化的重點(diǎn),也就是實(shí)現(xiàn)確保op_type與event_type已經(jīng)加了索引,其次確保索引用到了。
一、排序
- 盡量避免
- 排序的數(shù)據(jù)量盡量少,并保證在內(nèi)存里完成排序。
(至于具體什么數(shù)據(jù)量能在內(nèi)存中完成排序,不同數(shù)據(jù)庫(kù)有不同的配置:oracle是sort_area_size;postgresql是work_mem (integer),單位是KB,默認(rèn)值是4MB。mysql是sort_buffer_size 注意:該參數(shù)對(duì)應(yīng)的分配內(nèi)存是每連接獨(dú)占?。?/p>
二、索引
- 過(guò)濾的數(shù)據(jù)量比較少,一般來(lái)說(shuō)<20%,應(yīng)該走索引。20%-40% 可能走索引也可能不走索引。> 40% ,基本不走索引(會(huì)全表掃描)
- 保證值的數(shù)據(jù)類型和字段數(shù)據(jù)類型要一直。
- 對(duì)索引的字段進(jìn)行計(jì)算時(shí),必須在運(yùn)算符右側(cè)進(jìn)行計(jì)算。也就是 to_char(oc.create_date, ‘yyyyMMdd’)是沒(méi)用的
- 表字段之間關(guān)聯(lián),盡量給相關(guān)字段上添加索引。
- 復(fù)合索引,遵從最左前綴的原則,即最左優(yōu)先。(單獨(dú)右側(cè)字段查詢沒(méi)有索引的)
三、連接查詢方式
1、hash join
- 放內(nèi)存里進(jìn)行關(guān)聯(lián)。
- 適用于結(jié)果集比較大的情況。
- 比如都是200000數(shù)據(jù)
2、nest loop
- 從結(jié)果1 逐行取出,然后與結(jié)果集2進(jìn)行匹配。
- 適用于兩個(gè)結(jié)果集,其中一個(gè)數(shù)據(jù)量遠(yuǎn)大于另外一個(gè)時(shí)。
- 結(jié)果集一:1000
- 結(jié)果集二:1000000
四、多表聯(lián)查時(shí)
在多表聯(lián)查時(shí),需要考慮連接順序問(wèn)題。
1、當(dāng)postgresql中進(jìn)行查詢時(shí),如果多表是通過(guò)逗號(hào),而不是join連接,那么連接順序是多表的笛卡爾積中取最優(yōu)的。如果有太多輸入的表, PostgreSQL規(guī)劃器將從窮舉搜索切換為基因概率搜索,以減少可能性數(shù)目(樣本空間)?;蛩阉骰ǖ臅r(shí)間少, 但是并不一定能找到最好的規(guī)劃。
2、對(duì)于JOIN
- LEFT JOIN / RIGHT JOIN 會(huì)一定程度上指定連接順序,但是還是會(huì)在某種程度上重新排列:
- FULL JOIN 完全強(qiáng)制連接順序。
如果要強(qiáng)制規(guī)劃器遵循準(zhǔn)確的JOIN連接順序,我們可以把運(yùn)行時(shí)參數(shù)join_collapse_limit設(shè)置為 1
PostgreSQL提供了一些性能調(diào)優(yōu)的功能
主要有如下幾個(gè)方面。
1.使用EXPLAIN
EXPLAIN命令可以查看執(zhí)行計(jì)劃,這個(gè)方法是我們最主要的調(diào)試工具。
2.及時(shí)更新執(zhí)行計(jì)劃中使用的統(tǒng)計(jì)信息
由于統(tǒng)計(jì)信息不是每次操作數(shù)據(jù)庫(kù)都進(jìn)行更新的,一般是在 VACUUM 、 ANALYZE 、 CREATE INDEX等DDL執(zhí)行的時(shí)候會(huì)更新統(tǒng)計(jì)信息,
因此執(zhí)行計(jì)劃所用的統(tǒng)計(jì)信息很有可能比較舊。 這樣執(zhí)行計(jì)劃的分析結(jié)果可能誤差會(huì)變大。
以下是表tenk1的相關(guān)的一部分統(tǒng)計(jì)信息。
SELECT relname, relkind, reltuples, relpages FROM pg_class WHERE relname LIKE 'tenk1%';
relname | relkind | reltuples | relpages |
---|---|---|---|
tenk1 | r | 10000 | 358 |
tenk1_hundred | i | 10000 | 30 |
tenk1_thous_tenthous | i | 10000 | 30 |
tenk1_unique1 | i | 10000 | 30 |
tenk1_unique2 | i | 10000 | 30 |
(5 rows)
其中 relkind是類型,r是自身表,i是索引index;reltuples是項(xiàng)目數(shù);relpages是所占硬盤的塊數(shù)。
3.明確用join來(lái)關(guān)聯(lián)表
一般寫法:
SELECT * FROM a, b, c WHERE a.id = b.id AND b.ref = c.id;
如果明確用join的話,執(zhí)行時(shí)候執(zhí)行計(jì)劃相對(duì)容易控制一些。
例子:
SELECT * FROM a CROSS JOIN b CROSS JOIN c WHERE a.id = b.id AND b.ref = c.id; SELECT * FROM a JOIN (b JOIN c ON (b.ref = c.id)) ON (a.id = b.id);
4.關(guān)閉自動(dòng)提交
(autocommit=false)
5.多次插入數(shù)據(jù)用copy命令更高效
我們有的處理中要對(duì)同一張表執(zhí)行很多次insert操作。這個(gè)時(shí)候我們用copy命令更有效率。因?yàn)閕nsert一次,其相關(guān)的index都要做一次,比較花費(fèi)時(shí)間。
6.臨時(shí)刪除index
有時(shí)候我們?cè)趥浞莺椭匦聦?dǎo)入數(shù)據(jù)的時(shí)候,如果數(shù)據(jù)量很大的話,要很幾個(gè)小時(shí)才能完成。這個(gè)時(shí)候可以先把index刪除掉。導(dǎo)入在建index。
7.外鍵關(guān)聯(lián)的刪除
如果表的有外鍵的話,每次操作都沒(méi)去check外鍵整合性。因此比較慢。數(shù)據(jù)導(dǎo)入后在建立外鍵也是一種選擇。
8.增加maintenance_work_mem參數(shù)大小
增加這個(gè)參數(shù)可以提升CREATE INDEX和ALTER TABLE ADD FOREIGN KEY的執(zhí)行效率。
9.增加checkpoint_segments參數(shù)的大小
增加這個(gè)參數(shù)可以提升大量數(shù)據(jù)導(dǎo)入時(shí)候的速度。
10.設(shè)置archive_mode無(wú)效
這個(gè)參數(shù)設(shè)置為無(wú)效的時(shí)候,能夠提升以下的操作的速度
CREATE TABLE AS SELECT
CREATE INDEX
ALTER TABLE SET TABLESPACE
CLUSTER
等。
11.最后執(zhí)行VACUUM ANALYZE
表中數(shù)據(jù)大量變化的時(shí)候建議執(zhí)行VACUUM ANALYZE。
對(duì)生產(chǎn)運(yùn)行的數(shù)據(jù)庫(kù)要用定時(shí)任務(wù)crontb執(zhí)行如下操作:
psql -U username -d databasename -c "vacuum verbose analyze tablename;"
PostgreSQL 參數(shù)設(shè)置
autovacuum 相關(guān)參數(shù)
autovacuum: 默認(rèn)為on,表示是否開起autovacuum。默認(rèn)開起。特別的,當(dāng)需要凍結(jié)xid時(shí),盡管此值為off,PG也會(huì)進(jìn)行vacuum。 autovacuum_naptime: 下一次vacuum的時(shí)間,默認(rèn)1min。 這個(gè)naptime會(huì)被vacuum launcher分配到每個(gè)DB上。autovacuum_naptime/num of db。 log_autovacuum_min_duration: 記錄autovacuum動(dòng)作到日志文件,當(dāng)vacuum動(dòng)作超過(guò)此值時(shí)。 “-1”表示不記錄?!?”表示每次都記錄。 autovacuum_max_workers: 最大同時(shí)運(yùn)行的worker數(shù)量,不包含launcher本身。 autovacuum_work_mem: 每個(gè)worker可使用的最大內(nèi)存數(shù)。 autovacuum_vacuum_threshold: 默認(rèn)50。與autovacuum_vacuum_scale_factor配合使用,autovacuum_vacuum_scale_factor默認(rèn)值為20%。當(dāng)update,delete的tuples數(shù)量超過(guò)autovacuum_vacuum_scale_factor*table_size+autovacuum_vacuum_threshold時(shí),進(jìn)行vacuum。如果要使vacuum工作勤奮點(diǎn),則將此值改小。 autovacuum_analyze_threshold: 默認(rèn)50。與autovacuum_analyze_scale_factor配合使用。 autovacuum_analyze_scale_factor: 默認(rèn)10%。當(dāng)update,insert,delete的tuples數(shù)量超過(guò)autovacuum_analyze_scale_factor*table_size+autovacuum_analyze_threshold時(shí),進(jìn)行analyze。 autovacuum_freeze_max_age:200 million。離下一次進(jìn)行xid凍結(jié)的最大事務(wù)數(shù)。 autovacuum_multixact_freeze_max_age: 400 million。離下一次進(jìn)行xid凍結(jié)的最大事務(wù)數(shù)。 autovacuum_vacuum_cost_delay: 如果為-1,取vacuum_cost_delay值。 autovacuum_vacuum_cost_limit: 如果為-1,到vacuum_cost_limit的值,這個(gè)值是所有worker的累加值。
選項(xiàng) | 默認(rèn)值 | 說(shuō)明 | 是否優(yōu)化 | 原因 |
---|---|---|---|---|
max_connections | 100 | 允許客戶端連接的最大數(shù)目 | 否 | 因?yàn)樵跍y(cè)試的過(guò)程中,100個(gè)連接已經(jīng)足夠 |
fsync | on | 強(qiáng)制把數(shù)據(jù)同步更新到磁盤 | 是 | 因?yàn)橄到y(tǒng)的IO壓力很大,為了更好的測(cè)試其他配置的影響,把改參數(shù)改為off |
shared_buffers | 24MB | 決定有多少內(nèi)存可以被PostgreSQL用于緩存數(shù)據(jù)(推薦內(nèi)存的1/4) | 是 | 在IO壓力很大的情況下,提高該值可以減少IO |
work_mem | 1MB | 使內(nèi)部排序和一些復(fù)雜的查詢都在這個(gè)buffer中完成 | 是 | 有助提高排序等操作的速度,并且減低IO |
effective_cache_size | 128MB | 優(yōu)化器假設(shè)一個(gè)查詢可以用的最大內(nèi)存,和shared_buffers無(wú)關(guān)(推薦內(nèi)存的1/2) | 是 | 設(shè)置稍大,優(yōu)化器更傾向使用索引掃描而不是順序掃描 |
maintenance_work_mem | 16MB | 這里定義的內(nèi)存只是被VACUUM等耗費(fèi)資源較多的命令調(diào)用時(shí)使用 | 是 | 把該值調(diào)大,能加快命令的執(zhí)行 |
wal_buffer | 768kB | 日志緩存區(qū)的大小 | 是 | 可以降低IO,如果遇上比較多的并發(fā)短事務(wù),應(yīng)該和commit_delay一起用 |
checkpoint_segments | 3 | 設(shè)置wal log的最大數(shù)量數(shù)(一個(gè)log的大小為16M) | 是 | 默認(rèn)的48M的緩存是一個(gè)嚴(yán)重的瓶頸,基本上都要設(shè)置為10以上 |
checkpoint_completion_target | 0.5 | 表示checkpoint的完成時(shí)間要在兩個(gè)checkpoint間隔時(shí)間的N%內(nèi)完成 | 是 | 能降低平均寫入的開銷 |
commit_delay | 0 | 事務(wù)提交后,日志寫到wal log上到wal_buffer寫入到磁盤的時(shí)間間隔。需要配合commit_sibling | 是 | 能夠一次寫入多個(gè)事務(wù),減少IO,提高性能 |
commit_siblings | 5 | 設(shè)置觸發(fā)commit_delay的并發(fā)事務(wù)數(shù),根據(jù)并發(fā)事務(wù)多少來(lái)配置 | 是 | 減少IO,提高性能 |
autovacuum_naptime | 1min | 下一次vacuum任務(wù)的時(shí)間 | 是 | 提高這個(gè)間隔時(shí)間,使他不是太頻繁 |
autovacuum_analyze_threshold | 50 | 與autovacuum_analyze_scale_factor配合使用,來(lái)決定是否analyze | 是 | 使analyze的頻率符合實(shí)際 |
autovacuum_analyze_scale_factor | 0.1 | 當(dāng)update,insert,delete的tuples數(shù)量超過(guò)autovacuum_analyze_scale_factor*table_size+autovacuum_analyze_threshold時(shí),進(jìn)行analyze。 | 是 | 使analyze的頻率符合實(shí)際 |
pg中性能相關(guān)常調(diào)參數(shù)
參數(shù)名稱 | 參數(shù)意義 | 優(yōu)化思路 |
---|---|---|
shared_buffers | 數(shù)據(jù)庫(kù)服務(wù)器將使用的共享內(nèi)存緩沖區(qū)大小,該緩沖區(qū)為所有連接共用。從磁盤讀入的數(shù)據(jù)(主要包括表和索引)都緩存在這里。 | 提高該值可以減少數(shù)據(jù)庫(kù)的磁盤IO。 |
work_mem | 聲明內(nèi)部排序和哈希操作可使用的工作內(nèi)存大小。該內(nèi)存是在開始使用臨時(shí)磁盤文件之前使用的內(nèi)存數(shù)目。數(shù)值以kB為單位的,缺省是 1024 (1MB)。請(qǐng)注意對(duì)于復(fù)雜的查詢,可能會(huì)同時(shí)并發(fā)運(yùn)行好幾個(gè)排序或者哈希操作,每個(gè)都會(huì)使用這個(gè)參數(shù)聲明的這么多內(nèi)存,然后才會(huì)開始求助于臨時(shí)文件。同樣,好幾個(gè)正在運(yùn)行的會(huì)話可能會(huì)同時(shí)進(jìn)行排序操作。因此使用的總內(nèi)存可能是 work_mem 的好幾倍。ORDER BY, DISTINCT 和mergejoin都要用到排序操作,而哈希操作在哈希連接、哈希聚集和以哈希為基礎(chǔ)的 IN 子查詢處理中都會(huì)用到。該參數(shù)是會(huì)話級(jí)參數(shù)。 | 執(zhí)行排序操作時(shí),會(huì)根據(jù)work_mem的大小決定是否將一個(gè)大的結(jié)果集拆分為幾個(gè)小的和 work_mem差不多大小的臨時(shí)文件寫入外存。顯然拆分的結(jié)果是導(dǎo)致了IO,降低了排序的速度。因此增加work_mem有助于提高排序的速度。通常設(shè)置時(shí)可以逐漸調(diào)大,知道數(shù)據(jù)庫(kù)在排序的操作時(shí)不會(huì)有大量的寫文件操作即可。該內(nèi)存每個(gè)連接一份,當(dāng)并發(fā)連接較多時(shí)候,該值不宜過(guò)大。 |
effective_cache_size | 優(yōu)化器假設(shè)一個(gè)查詢可以使用的最大內(nèi)存(包括pg使用的和操作系統(tǒng)緩存),和shared_buffer等內(nèi)存無(wú)關(guān),只是給優(yōu)化器生成計(jì)劃使用的一個(gè)假設(shè)值。 | 設(shè)置稍大,優(yōu)化器更傾向使用索引掃描而不是順序掃描,建議的設(shè)置為可用空閑內(nèi)存的25%,這里的可用空閑內(nèi)存指的是主機(jī)物理內(nèi)存在運(yùn)行pg時(shí)得空閑值。 |
maintenance_work_mem | 這里定義的內(nèi)存只是在CREATE INDEX, VACUUM等時(shí)用到,因此用到的頻率不高,但是往往這些指令消耗比較多的資源,因此應(yīng)該盡快讓這些指令快速執(zhí)行完畢。 | 在數(shù)據(jù)庫(kù)導(dǎo)入數(shù)據(jù)后,執(zhí)行建索引等操作時(shí),可以調(diào)大,比如512M。 |
wal_buffers | 日志緩沖區(qū),日志緩沖區(qū)的大小。 | 兩種情況下要酌情調(diào)大:1.單事務(wù)的數(shù)據(jù)修改量很大,產(chǎn)生的日志大于wal_buffers,為了避免多次IO,調(diào)大該值。 |
2.系統(tǒng)中并發(fā)小數(shù)據(jù)量修改的短事務(wù)較多,并且設(shè)置了commit_delay,此時(shí)wal_buffers需要容納多個(gè)事務(wù)(commit_siblings個(gè))的日志,調(diào)大該值避免多次IO。 | ||
commit_delay | 事務(wù)提交后,日志寫到wal_buffer上到wal_buffer寫到磁盤的時(shí)間間隔。 | 如果并發(fā)的非只讀事務(wù)數(shù)目較多,可以適當(dāng)增加該值,使日志緩沖區(qū)一次刷盤可以刷出較多的事務(wù),減少IO次數(shù),提高性能。需要和commit_sibling配合使用。 |
commit_siblings | 觸發(fā)commit_delay等待的并發(fā)事務(wù)數(shù),也就是系統(tǒng)的并發(fā)活躍事務(wù)數(shù)達(dá)到了該值事務(wù)才會(huì)等待commit_delay的時(shí)間才將日志刷盤,如果系統(tǒng)中并發(fā)活躍事務(wù)達(dá)不到該值,commit_delay將不起作用,防止在系統(tǒng)并發(fā)壓力較小的情況下事務(wù)提交后空等其他事務(wù)。 | 應(yīng)根據(jù)系統(tǒng)并發(fā)寫的負(fù)載配置。例如統(tǒng)計(jì)出系統(tǒng)并發(fā)執(zhí)行增刪改操作的平均連接數(shù),設(shè)置該值為該平均連接數(shù)。 |
fsync | 設(shè)置為on時(shí),日志緩沖區(qū)刷盤時(shí),需要確認(rèn)已經(jīng)將其寫入了磁盤,設(shè)置為off時(shí),由操作系統(tǒng)調(diào)度磁盤寫的操作,能更好利用緩存機(jī)制,提高IO性能。 | 該性能的提高是伴隨了數(shù)據(jù)丟失的風(fēng)險(xiǎn),當(dāng)操作系統(tǒng)或主機(jī)崩潰時(shí),不保證刷出的日志是否真正寫入了磁盤。應(yīng)依據(jù)操作系統(tǒng)和主機(jī)的穩(wěn)定性來(lái)配置。 |
autovacuum | 是否開啟自動(dòng)清理進(jìn)程(如開啟需要同時(shí)設(shè)置參數(shù)stats_start_collector = on,stats_row_level = on,),整理數(shù)據(jù)文件碎片,更新統(tǒng)計(jì)信息。 | 如果系統(tǒng)中有大量的增刪改操作,建議打開自動(dòng)清理進(jìn)程,這樣一方面可以增加數(shù)據(jù)文件的物理連續(xù)性,減少磁盤的隨機(jī)IO,一方面可以隨時(shí)更新數(shù)據(jù)庫(kù)的統(tǒng)計(jì)信息,使優(yōu)化器可以選擇最優(yōu)的查詢計(jì)劃得到最好的查詢性能。如果系統(tǒng)中只有只讀的事務(wù),那么關(guān)閉自動(dòng)清理進(jìn)程。 |
autovacuum_naptime | 自動(dòng)清理進(jìn)程執(zhí)行清理分析的時(shí)間間隔 | 應(yīng)該根據(jù)數(shù)據(jù)庫(kù)的單位時(shí)間更新量來(lái)決定該值,一般來(lái)說(shuō)單位時(shí)間的更新量越大該時(shí)間間隔應(yīng)該設(shè)置越短。由于自動(dòng)清理對(duì)系統(tǒng)的開銷較大,該值應(yīng)該謹(jǐn)慎配置(不要過(guò)?。?。 |
bgwriter_delay | 后臺(tái)寫進(jìn)程的自動(dòng)執(zhí)行時(shí)間 | 后臺(tái)寫進(jìn)程的作用是將shared_buffer里的臟頁(yè)面寫回到磁盤,減少checkpoint的壓力,如果系統(tǒng)數(shù)據(jù)修改的壓力一直很大,建議將該時(shí)間間隔設(shè)置小一些,以免積累的大量的臟頁(yè)面到checkpoint,使checkpoint時(shí)間過(guò)長(zhǎng)(checkpoint期間系統(tǒng)響應(yīng)速度較慢)。 |
bgwriter_lru_maxpages | 后臺(tái)寫進(jìn)程一次寫出的臟頁(yè)面數(shù) | 依據(jù)系統(tǒng)單位時(shí)間數(shù)據(jù)的增刪改量來(lái)修改 |
bgwriter_lru_multiplier | 后臺(tái)寫進(jìn)程根據(jù)最近服務(wù)進(jìn)程需要的buffer數(shù)量乘上這個(gè)比率估算出下次服務(wù)進(jìn)程需要的buffer數(shù)量,在使用后臺(tái)寫進(jìn)程寫回臟頁(yè)面,使緩沖區(qū)能使用的干凈頁(yè)面達(dá)到這個(gè)估計(jì)值。 | 依據(jù)系統(tǒng)單位時(shí)間數(shù)據(jù)的增刪改量來(lái)修改。 |
總結(jié)
以上為個(gè)人經(jīng)驗(yàn),希望能給大家一個(gè)參考,也希望大家多多支持腳本之家。
相關(guān)文章
postgresql合并string_agg函數(shù)的實(shí)例
這篇文章主要介紹了postgresql合并string_agg函數(shù)的實(shí)例,具有很好的參考價(jià)值,希望對(duì)大家有所幫助。一起跟隨小編過(guò)來(lái)看看吧2021-01-01navicat無(wú)法連接postgreSQL-11的解決方案
這篇文章主要介紹了navicat無(wú)法連接postgreSQL-11的解決方案,具有很好的參考價(jià)值,希望對(duì)大家有所幫助。一起跟隨小編過(guò)來(lái)看看吧2020-12-12PostgreSQL LIST、RANGE 表分區(qū)的實(shí)現(xiàn)方案
這篇文章主要介紹了PostgreSQL LIST、RANGE 表分區(qū)的實(shí)現(xiàn)方案,具有很好的參考價(jià)值,希望對(duì)大家有所幫助。一起跟隨小編過(guò)來(lái)看看吧2021-01-01postgresql修改完端口后直接psql連接數(shù)據(jù)庫(kù)報(bào)錯(cuò)的解決
這篇文章主要介紹了postgresql修改完端口后直接psql連接數(shù)據(jù)庫(kù)報(bào)錯(cuò)的解決,具有很好的參考價(jià)值,具有很好的參考價(jià)值,希望對(duì)大家有所幫助。一起跟隨小編過(guò)來(lái)看看吧2021-01-01postgresql 刪除重復(fù)數(shù)據(jù)案例詳解
這篇文章主要介紹了postgresql 刪除重復(fù)數(shù)據(jù)案例詳解,本篇文章通過(guò)簡(jiǎn)要的案例,講解了該項(xiàng)技術(shù)的了解與使用,以下就是詳細(xì)內(nèi)容,需要的朋友可以參考下2021-08-08使用PostgreSQL的JSONB數(shù)據(jù)類型進(jìn)行高效查詢的示例代碼
PostgreSQL的JSONB數(shù)據(jù)類型提供了一種靈活的方式來(lái)存儲(chǔ)和查詢JSON格式的數(shù)據(jù),下面我們將詳細(xì)討論如何使用JSONB數(shù)據(jù)類型進(jìn)行高效查詢,并提供相應(yīng)的解決方案和示例代碼,需要的朋友可以參考下2024-04-04PgSQL條件語(yǔ)句與循環(huán)語(yǔ)句示例代碼詳解
這篇文章主要介紹了PgSQL條件語(yǔ)句與循環(huán)語(yǔ)句,pgSQL中有兩種條件語(yǔ)句分別為if與case語(yǔ)句,每種語(yǔ)句通過(guò)示例代碼給大家介紹的非常詳細(xì),需要的朋友可以參考下2022-07-07PostgreSQL教程(十九):SQL語(yǔ)言函數(shù)
這篇文章主要介紹了PostgreSQL教程(十九):SQL語(yǔ)言函數(shù),本文講解了SQL語(yǔ)言函數(shù)基本概念、基本類型、復(fù)合類型、帶輸出參數(shù)的函數(shù)、返回結(jié)果作為表數(shù)據(jù)源等內(nèi)容,需要的朋友可以參考下2015-05-05