一、序列的創(chuàng)建
1
2
3
4
5
6
|
CREATE SEQUENCE seq_bm_menuid INCREMENT 1 MINVALUE 1 MAXVALUE 999999999999999999 START 1 CACHE 5; |
大家從以上語句中可以看出當(dāng)前序列的cache為5,那么這個cache是在什么時候起作用呢?
二、遇到的序列跳值問題
當(dāng)我們的web應(yīng)用訪問postgresql數(shù)據(jù)庫,使用nextval('seq_bm_menuid')獲取序列值,然后插入到我們的業(yè)務(wù)表中時,發(fā)現(xiàn)業(yè)務(wù)表中該序列值對應(yīng)字段的值不連續(xù),以5為間隔發(fā)生跳躍,
如圖所示:
三、做個小實(shí)驗(yàn)
為了弄清楚序列跳值的原因,做個小實(shí)驗(yàn),方法如下:在pgAdmin中新建兩個查詢窗口,分別執(zhí)行select nextval('seq_bm_menuid');語句,當(dāng)在第一個查詢窗口執(zhí)行語句時,返回序列值為147;當(dāng)在第二個查詢窗口執(zhí)行語句時,返回序列值為152;果然還是間隔為5的產(chǎn)生序列值啊,繼續(xù)往下做就知道是怎么回事了。
我們回到第一個查詢窗口,再次執(zhí)行語句,此時返回序列值為148;再到第二個查詢窗口,再次執(zhí)行語句,此時返回序列值為153;到這里終于搞明白了序列的cache是作用于會話的,我們新建兩個查詢窗口實(shí)際是兩個會話,postgresql數(shù)據(jù)庫為每個會話cache了5個序列值,到此終于弄清楚了序列跳值的原因了。
補(bǔ)充:重新設(shè)置 PostGresql 序列起始值
修改設(shè)置 Postgresql 序列值的場景并不多見,一般在不規(guī)范使用數(shù)據(jù)庫的情況下存在!
有時候,數(shù)據(jù)庫的序列錯亂后,會發(fā)生 Detail: Key (xttblog_id)=(200007) already exists. 的錯誤提示。這種情況是說,200007 這個序列已經(jīng)被占用了。
修改這個錯誤的辦法有兩種
一種是執(zhí)行 nextval 函數(shù),跳過已存在的 key。
1
|
SELECT nextval( 'xttblog_id_seq' ); |
還有一種情況是,重新設(shè)置序列的起始值,跳過已經(jīng)存在的 key。
1
2
|
-- 序列重置到2020 alter sequence xttblog_id_seq restart with 2020 |
上面我重置序列到 2020。那序列就會從 2020 開始,之前小于 2020 的將會被跳過。
以上為個人經(jīng)驗(yàn),希望能給大家一個參考,也希望大家多多支持服務(wù)器之家。如有錯誤或未考慮完全的地方,望不吝賜教。
原文鏈接:https://blog.csdn.net/publishwy/article/details/10498973