记一次postgresql数据库函数执行问题

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;
...

12 1

...

2

BEGIN

3

4

FOR i IN 1..num LOOP

5

6

    SELECT func_process.sql() INTO counts;

7

8

    if counts = 0 then return ‘mac地址已使用完‘;

9

    end if;

10

11

end LOOP;

12

...

2、func_process.sql 没有入参，出参为完成状态值integer，里面共分五步：    a)、查询macInfo表，得到一条state=0的mac值【该表有65w条数据，且只有mac和state两个字段，mac为主键】

select mac from macInfo where state = 0 limit 1;

1 1

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

5 1

>> select "state", "count"("state") from macinfo GROUP BY state;

2

>> 

3

state count

4

1   641153

5

0   15000

3、因此为state加上索引。

CREATE INDEX "idx_macinfo_state" ON "usr"."macinfo" USING BTREE ("state");

1 1

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;

1 1

create table usr.macinfo_copy as select * from usr.macinfo;

2

DELETE FROM usr.macinfo where "state" <> 0;

6、再次执行，本次执行了1000条，发现耗时680s，换算成10000条也就是 10分钟多点。相比快了一倍，但是和最开始比还是慢了5倍。因此该方法还是不行
7、还原macinfo表，将数据还原成最初形式。再次执行。速度还是很慢，1000条500s。
五、小结发现就是macinfo表的原因，而且必定能重现。

记一次postgresql数据库函数执行问题

标签：因此   shell   引导   import   sele   class   mil   语句   执行