您好,登錄后才能下訂單哦!
本篇文章為大家展示了怎么在PostgreSQL中對表膨脹進行監控,內容簡明扼要并且容易理解,絕對能使你眼前一亮,通過這篇文章的詳細介紹希望你能有所收獲。
PostgreSQL自帶了pgstattuple模塊,可用于精確計算表的膨脹率。譬如這里的tuple_percent字段就是元組實際字節占關系總大小的百分比,用1減去該值即為膨脹率。
#插入1000W數據 postgres=# insert into t select id,id from generate_series(1,10000000) as id; INSERT 0 10000000 #表膨脹系數為0.097 postgres=# select *, 1.0 - tuple_len::numeric / table_len as bloat from pgstattuple('t'); table_len | tuple_count | tuple_len | tuple_percent | dead_tuple_count | dead_tuple_len | dead_tuple_percent | free_space | free_percent | bloat -----------+-------------+-----------+---------------+------------------+----------------+--------------------+------------+--------------+------------------------ 442818560 | 10000001 | 400000040 | 90.33 | 0 | 0 | 0 | 1304976 | 0.29 | 0.09669540499838127833 (1 row) #占用54055個page postgres=# select * from pg_relpages('t'); pg_relpages ------------- 54055 (1 row) #刪除數據 postgres=# delete from t where id<>10000000; DELETE 9999999 #仍然占用54055個page postgres=# select * from pg_relpages('t'); pg_relpages ------------- 54055 (1 row) #膨脹率已經為0.999999 postgres=# select *, 1.0 - tuple_len::numeric / table_len as bloat from pgstattuple('t'); table_len | tuple_count | tuple_len | tuple_percent | dead_tuple_count | dead_tuple_len | dead_tuple_percent | free_space | free_percent | bloat -----------+-------------+-----------+---------------+------------------+----------------+--------------------+------------+--------------+---------------------------- 442818560 | 2 | 80 | 0 | 9999999 | 399999960 | 90.33 | 1304976 | 0.29 | 0.999999819339099065766349 #vacuum表 postgres=# vacuum (verbose,full,analyze) t; INFO: vacuuming "public.t" INFO: "t": found 5372225 removable, 2 nonremovable row versions in 54055 pages DETAIL: 0 dead row versions cannot be removed yet. CPU: user: 0.89 s, system: 0.00 s, elapsed: 0.89 s. INFO: analyzing "public.t" INFO: "t": scanned 1 of 1 pages, containing 2 live rows and 0 dead rows; 2 rows in sample, 2 estimated total rows VACUUM
補充:pg索引膨脹問題---重建索引
發現數據庫中很多表的索引大小超過數據大小。經檢查,生產CA、CZ、MU、HU、PSG、RIUE庫都存在這個現象。
原因:據運行同事介紹索引膨脹問題無法避免,頻繁更新就會帶來這個問題。
對于大的索引可以采用重建的方式解決。以下兩種方法推薦第一種。
方法一:停止應用(這個操作會鎖表),重建索引(注:重建完索引名稱不變)
sql:reindex index 索引名稱
時間:速度較快。2G大小的表,基本上1分鐘左右可以建完索引。
還可以針對表重建索引,這個操作會加排他鎖 :
reindex table 表名
方法二:在線建新索引,再把舊索引刪除
sql:根據不同索引采用不同的建索引命令,例如:
普通索引
create index concurrently idx_tbl_2 on tbl(id); drop index idx_tbl_1;
唯一索引
create unique index concurrently user_info_username_key_1 on user_info(username); begin; alter table user_info drop constraint user_info_username_key; alter table user_info add constraint user_info_username_key unique using index user_info_username_key_1; end;
主鍵索引
create unique index concurrently user_info_pkey_1 on user_info(id); begin; alter table user_info drop constraint user_info_pkey; alter table user_info add constraint user_info_pkey primary key using index user_info_pkey_1; end;
時間:不停應用的話,業務忙的時候可能會非常長的時間。
多支持億速云。如有錯誤或未考慮完全的地方,望不吝賜教。
上述內容就是怎么在PostgreSQL中對表膨脹進行監控,你們學到知識或技能了嗎?如果還想學到更多技能或者豐富自己的知識儲備,歡迎關注億速云行業資訊頻道。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。