一、序列的創(chuàng)建

CREATE SEQUENCE seq_bm_menuid
 INCREMENT 1
 MINVALUE 1
 MAXVALUE 999999999999999999
 START 1
 CACHE 5;

大家從以上語(yǔ)句中可以看出當(dāng)前序列的cache為5，那么這個(gè)cache是在什么時(shí)候起作用呢？

二、遇到的序列跳值問(wèn)題

當(dāng)我們的web應(yīng)用訪問(wèn)postgresql數(shù)據(jù)庫(kù)，使用nextval('seq_bm_menuid')獲取序列值，然后插入到我們的業(yè)務(wù)表中時(shí)，發(fā)現(xiàn)業(yè)務(wù)表中該序列值對(duì)應(yīng)字段的值不連續(xù)，以5為間隔發(fā)生跳躍，

如圖所示：

三、做個(gè)小實(shí)驗(yàn)

為了弄清楚序列跳值的原因，做個(gè)小實(shí)驗(yàn)，方法如下：在pgAdmin中新建兩個(gè)查詢窗口，分別執(zhí)行select nextval('seq_bm_menuid');語(yǔ)句，當(dāng)在第一個(gè)查詢窗口執(zhí)行語(yǔ)句時(shí)，返回序列值為147；當(dāng)在第二個(gè)查詢窗口執(zhí)行語(yǔ)句時(shí)，返回序列值為152；果然還是間隔為5的產(chǎn)生序列值啊，繼續(xù)往下做就知道是怎么回事了。

我們回到第一個(gè)查詢窗口，再次執(zhí)行語(yǔ)句，此時(shí)返回序列值為148；再到第二個(gè)查詢窗口，再次執(zhí)行語(yǔ)句，此時(shí)返回序列值為153；到這里終于搞明白了序列的cache是作用于會(huì)話的，我們新建兩個(gè)查詢窗口實(shí)際是兩個(gè)會(huì)話，postgresql數(shù)據(jù)庫(kù)為每個(gè)會(huì)話cache了5個(gè)序列值，到此終于弄清楚了序列跳值的原因了。

補(bǔ)充：重新設(shè)置 PostGresql 序列起始值

修改設(shè)置 Postgresql 序列值的場(chǎng)景并不多見，一般在不規(guī)范使用數(shù)據(jù)庫(kù)的情況下存在！

有時(shí)候，數(shù)據(jù)庫(kù)的序列錯(cuò)亂后，會(huì)發(fā)生 Detail: Key (xttblog_id)=(200007) already exists. 的錯(cuò)誤提示。這種情況是說(shuō)，200007 這個(gè)序列已經(jīng)被占用了。

修改這個(gè)錯(cuò)誤的辦法有兩種

一種是執(zhí)行 nextval 函數(shù)，跳過(guò)已存在的 key。

SELECT nextval('xttblog_id_seq');

還有一種情況是，重新設(shè)置序列的起始值，跳過(guò)已經(jīng)存在的 key。

-- 序列重置到2020
alter sequence xttblog_id_seq restart with 2020

上面我重置序列到 2020。那序列就會(huì)從 2020 開始，之前小于 2020 的將會(huì)被跳過(guò)。

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。如有錯(cuò)誤或未考慮完全的地方，望不吝賜教。

最新評(píng)論