我想提高我的数据库性能。在一个项目中,所有表格都从int
变为bigint
,我认为这不仅仅是关于存储的错误选择,因为int
需要4 bytes
和{{1} }需要bigint
;还需要考虑性能。
所以我创建了一个包含 1000万条目的小表,其中的脚本位于8 bytes
Python:
这就是我创建import uuid
rows=10000000
output='insert_description_bigint.sql'
f = open(output, 'w')
set_schema="SET search_path = norma;\n"
f.write(set_schema)
for i in range(1,rows):
random_string=uuid.uuid4()
query="insert into description_bigint (description_id, description) values (%d, '%s'); \n"
f.write(query % (i,random_string))
表格的方式:
two
插入所有这些数据后,我对两个表进行查询,以测量它们之间的差异。令我惊讶的是,他们都有相同的表现:
-- BIGINT
DROP TABLE IF EXISTS description_bigint;
CREATE TABLE description_bigint
(
description_id BIGINT PRIMARY KEY NOT NULL,
description VARCHAR(200),
constraint description_id_positive CHECK (description_id >= 0)
);
select count(1) from description_bigint;
select * from description_bigint;
select * from description_bigint where description_id = 9999999;
-- INT
DROP TABLE IF EXISTS description_int;
CREATE TABLE description_int
(
description_id INT PRIMARY KEY NOT NULL,
description VARCHAR(200),
constraint description_id_positive CHECK (description_id >= 0)
);
我的基准测试有问题吗?不应该select * from description_bigint; -- 11m55s
select * from description_int; -- 11m55s
比int
更快吗?特别是,如果bigint
定义为primary key
,则意味着为index
创建索引更慢,而不是为{{1}创建索引对于相同数量的数据,对吧?
我知道这不仅仅会对我的数据库的性能产生巨大影响,但我希望确保我们使用最佳实践并专注于此处的性能。
答案 0 :(得分:13)
在64系统中,两个表几乎完全相同。 description_id
中的description_int
列覆盖了8个字节(整数为4,对齐为4)。试试这个测试:
select
pg_relation_size('description_int')/10000000 as table_int,
pg_relation_size('description_bigint')/10000000 as table_bigint,
pg_relation_size('description_int_pkey')/10000000 as index_int,
pg_relation_size('description_bigint_pkey')/10000000 as index_bigint;
两个表的平均行大小几乎相同。这是因为整数列占用8个字节(一个值为4个字节,对齐为4个字节),与bigint完全相同(对于没有填充符的值,为8个字节)。这同样适用于索引条目。然而,这是一个特例。如果我们在第一个表中再添加一个整数列:
CREATE TABLE two_integers
(
description_id INT PRIMARY KEY NOT NULL,
one_more_int INT,
description VARCHAR(200),
constraint description_id_positive CHECK (description_id >= 0)
);
平均行大小应保持不变。