一、函数说明：
首先编写了三个函数：
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;
...12
1
...2
BEGIN3
4
FOR i IN 1..num LOOP5
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 150005
1
>> select "state", "count"("state") from macinfo GROUP BY state;2
>> 3
state count4
1 6411535
0 150003、因此为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表的原因，而且必定能重现。