sql – 作为PK的顺序索引的填充因子

前端之家收集整理的这篇文章主要介绍了sql – 作为PK的顺序索引的填充因子前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
是的,再次填充因子.我花了很多时间阅读,我无法确定每个案例哪个是更好的填充因子.问题是我不明白碎片何时以及如何制作.我正在将数据库从MS sql Server迁移到Postgresql 9.2.

情况1)连续(连续)PK中10-50次插入/分钟,每小时20-50次读取.

CREATE TABLE dev_transactions
(
  transaction_id serial NOT NULL,transaction_type smallint NOT NULL,moment timestamp without time zone NOT NULL,gateway integer NOT NULL,device integer NOT NULL,controler smallint NOT NULL,token integer,et_mode character(1),status smallint NOT NULL,CONSTRAINT pk_dev_transactions PRIMARY KEY (transaction_id)
)
WITH (
  OIDS=FALSE
);

情况2)PK顺序的类似结构索引将以每个2个月~50,000个寄存器的块(一次)写入,读数为10-50 /分钟.

50%的填充因子意味着在每个插入中将生成一个新页面并将50%的现有记录传输到新的生成页面

50%的填充因子意味着在创建新页面时,将保留复制的记录以避免在两者之间插入?

只有在没有空间分配记录时才会生成页面

你可以看到我很困惑;我会很感激它的一些帮助 – 也许是阅读有关Postgresql和索引填充因子的好链接.

解决方法

FILLFACTOR

只使用INSERT和SELECT,你应该在任何地方使用100的FILLFACTOR.

如果您不打算使用UPDATE“摆动”,那么每个内存块的摆动空间是没有意义的.

FILLFACTOR背后的机制非常简单. INSERT仅填充每个数据页(通常为8 kb块),最多为FILLFACTOR设置声明的百分比.此外,无论何时在桌面上运行VACUUM FULL或CLUSTER,都会重新建立每个块的相同摆动空间.理想情况下,这允许UPDATE在同一数据页中存储新行版本,这可以在处理大量UPDATE时提供显着的性能提升.与H.O.T.结合使用也是有益的.更新:

> Redundant data in update statements

如果没有更新,请不要为此浪费空间并设置FILLFACTOR = 100.

基本信息来源:CREATE TABLE手册或CREATE INDEX.

其他优化

但你可以做别的事 – 因为你似乎是一个优化的傻瓜… 原文链接:https://www.f2er.com/mssql/84251.html

猜你在找的MsSQL相关文章