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