记一次postgresql数据库函数执行问题
一、函数说明:
首先编写了三个函数:
func_init.sql
func_process.sql
func_uuid.sql
1、func_init.sql 入参为一个int类型number,根据传入的number做循环,循环调用func_process.sql。
... BEGIN FOR i IN 1..num LOOP SELECT func_process.sql() INTO counts; if counts = 0 then return 'mac地址已使用完'; end if; end LOOP; ...
2、func_process.sql 没有入参,出参为完成状态值integer,里面共分五步:
a)、查询macInfo表,得到一条state=0的mac值【该表有65w条数据,且只有mac和state两个字段,mac为主键】
select mac from macInfo where state = 0 limit 1;
b)、调用func_uuid.sql,得到uuid【该方法通过plpythonu语言编写,生成UUID】
c)、生成各个sequence(大概12个)
d)、组装12个insert语句(12张表)【这里用到了第a步里得到的mac】
e)、更新macInfo表,将mac值对应的数据的state改为1。
3、func_uuid.sql
通过plpythonu语言编写,生成UUID,与sql无关。
二、postgresql函数问题:
单个函数就是一个事物,无法主动提交事物。
也就是说,我func_init传入的值是多少,那么必须这些全部处理完才会提交事务,中途无法主动提交。
三、前提如下:
由于一开始没有特别的考虑性能问题,使用了insert into,而不是copy。
macInfo表里state没有建立索引。
一开始macInfo表的所有state都为0。
写了一个python脚本,在服务器循环调用func_init(10000),调用了65次,用来规避postgresql无法主动提交事务问题。
四、发生的问题以及排查
1、一开始跑的时候,
前几次func_init(10000),也就是执行10000次func_process,耗时135s。
当func_init(10000)跑到第60次的时候,发现耗时非常久,需要20分钟多。
也就是速度慢了10倍。
检查postgresql所在服务器,发现当执行函数的时候,会将一个cpu占到90%,占所有cpu的6%。
当这个函数执行完成时,几乎不占,因此可以确定是这个函数造成的。
2、经过排除,发现是第a步,查询mac非常慢,每次耗时100ms。原本耗时是7ms。
猜想macInfo表中state当时值分布中为0的已经很少,都是为1的,且没有索引导致查询慢。
>> select "state", "count"("state") from macinfo GROUP BY state; >> state count 1 641153 0 15000
3、因此为state加上索引。
CREATE INDEX "idx_macinfo_state" ON "usr"."macinfo" USING BTREE ("state");
4、再次执行,发现速度还是很慢,几乎没有改变。
5、既然索引没用,那么我删掉state为1的数据,只留下15000条state为0的数据。
create table usr.macinfo_copy as select * from usr.macinfo; DELETE FROM usr.macinfo where "state" <> 0;
6、再次执行,本次执行了1000条,发现耗时680s,换算成10000条也就是 10分钟多点。
相比快了一倍,但是和最开始比还是慢了5倍。因此该方法还是不行
7、还原macinfo表,将数据还原成最初形式。再次执行。速度还是很慢,1000条500s。
五、小结
发现就是macinfo表的原因,而且必定能重现。
![](https://images.cnblogs.com/cnblogs_com/churao/889701/o_%E5%85%AC%E4%BC%97%E5%8F%B7.jpg)