這篇文章主要介紹了解決postgresql 序列跳值的問題，具有很好的參考價值，希望對大家有所幫助。一起跟隨小編過來看看吧。
一、序列的創(chuàng)建
CREATE SEQUENCE seq_bm_menuid
INCREMENT 1
MINVALUE 1
MAXVALUE 999999999999999999
START 1
CACHE 5;
大家從以上語句中可以看出當前序列的cache為5，那么這個cache是在什么時候起作用呢？
二、遇到的序列跳值問題
當我們的web應用訪問postgresql數(shù)據(jù)庫，使用nextval('seq_bm_menuid')獲取序列值，然后插入到我們的業(yè)務表中時，發(fā)現(xiàn)業(yè)務表中該序列值對應字段的值不連續(xù)，以5為間隔發(fā)生跳躍，
如圖所示：
三、做個小實驗
為了弄清楚序列跳值的原因，做個小實驗，方法如下：在pgAdmin中新建兩個查詢窗口，分別執(zhí)行select nextval('seq_bm_menuid');語句，當在第一個查詢窗口執(zhí)行語句時，返回序列值為147；當在第二個查詢窗口執(zhí)行語句時，返回序列值為152；果然還是間隔為5的產(chǎn)生序列值啊，繼續(xù)往下做就知道是怎么回事了。
我們回到第一個查詢窗口，再次執(zhí)行語句，此時返回序列值為148；再到第二個查詢窗口，再次執(zhí)行語句，此時返回序列值為153；到這里終于搞明白了序列的cache是作用于會話的，我們新建兩個查詢窗口實際是兩個會話，postgresql數(shù)據(jù)庫為每個會話cache了5個序列值，到此終于弄清楚了序列跳值的原因了。
補充：重新設置 PostGresql 序列起始值
修改設置 Postgresql 序列值的場景并不多見，一般在不規(guī)范使用數(shù)據(jù)庫的情況下存在！
有時候，數(shù)據(jù)庫的序列錯亂后，會發(fā)生 Detail: Key (xttblog_id)=(200007) already exists. 的錯誤提示。這種情況是說，200007 這個序列已經(jīng)被占用了。
修改這個錯誤的辦法有兩種
一種是執(zhí)行 nextval 函數(shù)，跳過已存在的 key。
1SELECT nextval('xttblog_id_seq');
還有一種情況是，重新設置序列的起始值，跳過已經(jīng)存在的 key。
-- 序列重置到2020alter sequence xttblog_id_seq restart with 2020
上面我重置序列到 2020。那序列就會從 2020 開始，之前小于 2020 的將會被跳過。
文章來源：腳本之家
來源地址：https://www.jb51.net/article/205234.htm
申請創(chuàng)業(yè)報道，分享創(chuàng)業(yè)好點子。點擊此處，共同探討創(chuàng)業(yè)新機遇！
