膨胀率的精确计算
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;
时间:不停应用的话,业务忙的时候可能会非常长的时间。
以上为个人经验,希望能给大家一个参考,也希望大家多多支持。如有错误或未考虑完全的地方,望不吝赐教。
华山资源网 Design By www.eoogi.com
广告合作:本站广告合作请联系QQ:858582 申请时备注:广告合作(否则不回)
免责声明:本站资源来自互联网收集,仅供用于学习和交流,请遵循相关法律法规,本站一切资源不代表本站立场,如有侵权、后门、不妥请联系本站删除!
免责声明:本站资源来自互联网收集,仅供用于学习和交流,请遵循相关法律法规,本站一切资源不代表本站立场,如有侵权、后门、不妥请联系本站删除!
华山资源网 Design By www.eoogi.com
暂无评论...
RTX 5090要首发 性能要翻倍!三星展示GDDR7显存
三星在GTC上展示了专为下一代游戏GPU设计的GDDR7内存。
首次推出的GDDR7内存模块密度为16GB,每个模块容量为2GB。其速度预设为32 Gbps(PAM3),但也可以降至28 Gbps,以提高产量和初始阶段的整体性能和成本效益。
据三星表示,GDDR7内存的能效将提高20%,同时工作电压仅为1.1V,低于标准的1.2V。通过采用更新的封装材料和优化的电路设计,使得在高速运行时的发热量降低,GDDR7的热阻比GDDR6降低了70%。
更新日志
2024年12月28日
2024年12月28日
- 小骆驼-《草原狼2(蓝光CD)》[原抓WAV+CUE]
- 群星《欢迎来到我身边 电影原声专辑》[320K/MP3][105.02MB]
- 群星《欢迎来到我身边 电影原声专辑》[FLAC/分轨][480.9MB]
- 雷婷《梦里蓝天HQⅡ》 2023头版限量编号低速原抓[WAV+CUE][463M]
- 群星《2024好听新歌42》AI调整音效【WAV分轨】
- 王思雨-《思念陪着鸿雁飞》WAV
- 王思雨《喜马拉雅HQ》头版限量编号[WAV+CUE]
- 李健《无时无刻》[WAV+CUE][590M]
- 陈奕迅《酝酿》[WAV分轨][502M]
- 卓依婷《化蝶》2CD[WAV+CUE][1.1G]
- 群星《吉他王(黑胶CD)》[WAV+CUE]
- 齐秦《穿乐(穿越)》[WAV+CUE]
- 发烧珍品《数位CD音响测试-动向效果(九)》【WAV+CUE】
- 邝美云《邝美云精装歌集》[DSF][1.6G]
- 吕方《爱一回伤一回》[WAV+CUE][454M]