某张表有一批记录，A用户说，这批记录是我要的，但是我只要一条，B用户也说，这批记录是我要的，我也只要一条。
是不是有点像一群男人去逛怡红院，妹子们都是目标，但是今晚只要一位，至于是谁暂时还不确定，虽然不需要抢，但是得锁单。
被动分配式，等着妈妈给你分一个。
主动挑选式，主动到姑娘们群里挑，就涉及到锁单的问题了，一个妹子只能陪一位公子哦。
上面的例子可能不太适合未成年人，那么看看另一个形象的比喻，某处有一堆砖块，每块砖头都有一个唯一编号，然后一群小伙伴同时来取砖块（每人每次取1块），要求每个小伙伴拿到的砖块ID是随机的，并且要求以最快的方式将砖块取完。
这次真的来搬砖了，来比一比谁的搬砖能力强吧。
我们将问题转化一下，一块砖一个ID，作为一条记录存入数据库，假设我们有1000万块砖。有128个小伙伴同时来搬砖，怎么能以最快的速度，随机的把砖搬完呢？
这个场景实际上有一个来头，某个群红包口令业务，由于该业务没有对接账务系统，没有用户ID也没有用户手机号，所以没法将领红包的资格做判定，为了防止任何人都能猜测口令的方式来领取红包，搞了一个批量生成随机口令的方法，发红包的时候从数据库取走一条(随机口令)。既要考虑随机，又要考虑用户体验，所以选择了8位数值（比较容易猜测），然后又要考虑高并发的发红包场景，所以还要求取值快。
理解了需求后，我们看看如何优化？
考虑随机、并发还不够，因为数据要取走（转移到一个已消耗的表中），因此还需要考虑数据的收缩。
比如PostgreSQL的堆表，末端的空数据块是可以被回收的，那么我们在设计的时候，如果能从末端开始取，是最好的。
1. 插入时就让数据随机，而不是取时随机。
创建测试表, 存放一堆唯一值.
postgres=# create table tbl (id int); CREATE TABLE唯一值随机插入, 取数据时按照数据块倒序取出, 这么做的好处是vacuum时可以直接回收这部分空间.
postgres=# select * from generate_series(1,10) order by random(); generate_series ----------------- 1 9 4 7 3 6 8 2 10 5 (10 rows) postgres=# \timing Timing is on.随机的插入1000万数据
postgres=# insert into tbl select * from generate_series(1,10000000) order by random(); INSERT 0 10000000 Time: 42204.425 ms从数据来看 , 已经随机插入了.
postgres=# select * from tbl limit 10; id --------- 9318426 4366165 4661718 8491396 9413591 9845650 8830805 999712 7944907 2487468 (10 rows)在ctid(行号)上创建索引, 取数据时使用这个索引, 倒序从最后的数据块开始取数据.
postgres=# create index idx_tbl_ctid on tbl(ctid); CREATE INDEX Time: 18824.496 ms 9.x开始不支持对系统列创建索引，所以我们可以增加一个自增主键 drop table tbl; create table tbl (pk serial8 primary key, id int); insert into tbl (id) select * from generate_series(1,10000000) order by random();例如:
postgres=# select ctid,* from tbl order by pk desc limit 5; ctid | pk | id ------------+----------+--------- (54054,10) | 10000000 | 2168083 (54054,9) | 9999999 | 5812175 (54054,8) | 9999998 | 1650372 (54054,7) | 9999997 | 2443217 (54054,6) | 9999996 | 3002493 (5 rows)为了防止多个进程重复取数据, 使用这种方法.
postgres=# with t as(select pk from tbl order by pk desc limit 5) delete from tbl where pk in (select pk from t) returning *; pk | id ----------+--------- 9999997 | 2443217 9999999 | 5812175 10000000 | 2168083 9999996 | 3002493 9999998 | 1650372 (5 rows) DELETE 5测试并行取数据.
测试方法, 将数据插入另一张表，表示数据从一张表搬运到另一张表。
create table test(like tbl); postgres=# with t as(select pk from tbl order by pk desc limit 5), t1 as (delete from tbl where pk in (select pk from t) returning *) insert into test select * from t1 returning * ; pk | id ---------+--------- 9999993 | 5893249 9999995 | 6079644 9999994 | 1834403 9999992 | 3511813 9999991 | 7078819 (5 rows) INSERT 0 5 postgres=# select * from test; pk | id ---------+--------- 9999993 | 5893249 9999995 | 6079644 9999994 | 1834403 9999992 | 3511813 9999991 | 7078819 (5 rows)使用pgbench 测试, 16个并行取数据进程, 每次取5条.
postgres@localhost-> vi test.sql with t as(select pk from tbl order by pk desc limit 5),t1 as (delete from tbl where pk in (select pk from t) returning *) insert into test select * from t1 returning * ;测试完成后, 查询test表, 看看有没有重复数据就知道这种方法是否靠谱了.
性能见下 :
transaction type: ./test.sql scaling factor: 1 query mode: prepared number of clients: 64 number of threads: 64 duration: 30 s number of transactions actually processed: 1053020 latency average = 1.819 ms latency stddev = 1.126 ms tps = 35083.102896 (including connections establishing) tps = 35149.046180 (excluding connections establishing) script statistics: - statement latencies in milliseconds: 1.821 with t as(select pk from tbl order by pk desc limit 5),t1 as (delete from tbl where pk in (select pk from t) returning *) insert into test select * from t1 returning * ;经查没有重复数据, 方法靠谱，搬砖成功
postgres=# select count(*),count(distinct id) from test; count | count --------+-------- 143400 | 143400 (1 row)以上方法数据是从堆表的末端开始搬运的，所以表会随着搬运，autovacuum使之变小。
但是实际上，以上QUERY有一个问题，select没有加锁，在delete时，可能已经被其他并发进程搬走了。竞争的问题也被掩盖了。
为了改善这个问题，比如要求每次请求，必须搬走1块砖。那么需要加LIMIT 1 for update skip locked，这样能解决竞争的问题，但是无法解决重复扫描的问题。
我们先看看效果
postgres@localhost-> vi test.sql with t as(select pk from tbl order by pk desc limit 1 for update skip locked), t1 as (delete from tbl where pk in (select pk from t) returning *) insert into test select * from t1 returning * ; $ pgbench -M prepared -n -r -P 1 -f ./test.sql -c 64 -j 64 -T 30 progress: 1.0 s, 4646.7 tps, lat 12.035 ms stddev 32.066 progress: 2.0 s, 4106.0 tps, lat 15.782 ms stddev 40.525 progress: 3.0 s, 4173.0 tps, lat 15.440 ms stddev 37.953 progress: 4.0 s, 4077.0 tps, lat 15.336 ms stddev 38.641 progress: 5.0 s, 4138.0 tps, lat 15.869 ms stddev 41.051 progress: 6.0 s, 4173.0 tps, lat 14.902 ms stddev 41.100 progress: 7.0 s, 4189.9 tps, lat 15.673 ms stddev 41.54064个搬运工，每秒只能搬运4000条左右。
因为他们中最差的那个询问了64块砖才拿到搬运这块砖头的所有权，只有第一个人，询问了1块砖就拿到了所有权。
那么怎么优化呢? 如何让每个搬运工每次拿到的砖头ID都是随机的，并且没人和他抢。
如何拿到随机的记录是关键，PostgreSQL提供了一个随机访问接口tablesample，通过这个接口，可以随机访问数据（提供一个百分比1-100即可），注意随机访问的数据是在where过滤条件前，所以百分比太小的话，你可能会访问不到任何数据。
目前支持两种随机采样方法，1. system，按块随机(整个数据块的记录被取出)；2. BERNOULLI扫全表，按百分比返回随机记录；因此BERNOULLI比SYSTEM随机度更精准，但是SYSTEM的效率更高。
create or replace function exchange_t(i_limit int8, sample_ratio real) returns setof tbl as $$ declare -- 总共搬几块砖 res_cnt int8 := i_limit; -- 抢到的砖块ID pk_arr int8[]; -- 这次搬了几块(极少情况, 可能有一些被别抢去了) tmp_cnt int8; -- 最多循环次数 max_cnt int := 16; begin loop -- 无耻的搬砖优化，通过PostgreSQL采样接口，随机取砖头 select array_agg(pk) into pk_arr from (select pk from tbl TABLESAMPLE SYSTEM (sample_ratio) limit res_cnt) t ; -- 或者 select array_agg(pk) into pk_arr from (select pk from tbl TABLESAMPLE BERNOULLI (sample_ratio) limit res_cnt) t ; if found then -- 搬砖，并返回已搬走的砖头ID return query with tmp as (delete from tbl where pk = any (pk_arr) returning *) insert into test select * from tmp returning *; -- 这次搬了几块砖，还需要搬几块 GET DIAGNOSTICS tmp_cnt = ROW_COUNT; -- raise notice 'tmp_cnt: %', tmp_cnt; res_cnt := res_cnt - tmp_cnt; -- raise notice 'res_cnt: %', res_cnt; end if; -- 如果搬完，返回 if (res_cnt <= 0) then return; end if; -- 防止无限循环 max_cnt := max_cnt - 1; if (max_cnt <=0 ) then return; end if; end loop; end; $$ language plpgsql strict; postgres=# select * from exchange_t(5, 0.1); NOTICE: tmp_cnt: 5 NOTICE: res_cnt: 0 pk | id -----+--------- 49 | 1035771 51 | 7966506 57 | 5967428 91 | 7405759 120 | 7764840 (5 rows)压测
搬砖性能从4000提升到了将近9万。
vi test.sql select * from exchange_t(1, 0.1); pgbench -M prepared -n -r -P 1 -f ./test.sql -c 64 -j 64 -T 30 transaction type: ./test.sql scaling factor: 1 query mode: prepared number of clients: 64 number of threads: 64 duration: 30 s number of transactions actually processed: 2677383 latency average = 0.714 ms latency stddev = 2.607 ms tps = 89200.726564 (including connections establishing) tps = 89417.041119 (excluding connections establishing) script statistics: - statement latencies in milliseconds: 0.717 select * from exchange_t(1, 0.1);除了这个搬砖场景，还有一些其他场景也能使用类似方法，感谢万能的PostgreSQL。
比如有一个场景初始化了一批账号ID，初始ID=0，每次有用户来注册时，将ID=0的记录修改为此次注册的用户ID，相当于消耗一条ID=0的记录。
使用采样的方法可以优化这个场景，不过别急着套用，因为数据采样是在过滤条件之前发生的，所以当所有数据范围都是我们的目标数据是没问题的，但是如果你把目标数据和非目标数据混到一起，这种采样的方法就可能导致冗余扫描，如果采样比例低，甚至找不到目标数据。因此前面的搬砖场景，我们每次都把数据搬走，剩余的所有数据依旧是目标数据，所以不存在问题。
那么了解了以上原理之后，第二个场景，我们也采样转移法，即申请ID的时候，将数据转移走，而不仅仅是UPDATE ID=NEWID的做法。
例子
初始表 create table tbl1(pk serial8 primary key, id int, info text, crt_time timestamp, mod_time timestamp); 转移表 create table tbl2(like tbl1); 初始数据1000万 insert into tbl1 (id, info, crt_time) select 0, 'test', now() from generate_series(1,10000000);函数
create or replace function exchange_t(i_limit int8, sample_ratio real, i_id int, i_mod_time timestamp) returns setof tbl2 as $$ declare -- 总共搬几块砖 res_cnt int8 := i_limit; -- 抢到的砖块ID pk_arr int8[]; -- 这次搬了几块(极少情况, 可能有一些被别抢去了) tmp_cnt int8; -- 最多循环次数 max_cnt int := 16; begin loop -- 无耻的搬砖优化，通过PostgreSQL采样接口，随机取砖头 select array_agg(pk) into pk_arr from (select pk from tbl1 TABLESAMPLE SYSTEM (sample_ratio) limit res_cnt) t ; -- 或者 select array_agg(pk) into pk_arr from (select pk from tbl1 TABLESAMPLE BERNOULLI (sample_ratio) limit res_cnt) t ; if found then -- 搬砖，并返回已搬走的砖头ID return query with tmp as (delete from tbl1 where pk = any (pk_arr) returning pk,info,crt_time) insert into tbl2(pk,id,info,crt_time,mod_time) select pk,i_id,info,crt_time,i_mod_time from tmp returning *; -- 这次搬了几块砖，还需要搬几块 GET DIAGNOSTICS tmp_cnt = ROW_COUNT; -- raise notice 'tmp_cnt: %', tmp_cnt; res_cnt := res_cnt - tmp_cnt; -- raise notice 'res_cnt: %', res_cnt; end if; -- 如果搬完，返回 if (res_cnt <= 0) then return; end if; -- 防止无限循环 max_cnt := max_cnt - 1; if (max_cnt <=0 ) then return; end if; end loop; end; $$ language plpgsql strict;测试
postgres=# select exchange_t(1,0.1,10,now()); exchange_t --------------------------------------------------------------------------- (360129,10,test,"2017-03-03 16:48:58.86919","2017-03-03 16:51:13.969138") (1 row) Time: 0.724 ms postgres=# select count(*) from tbl1; count --------- 9999997 (1 row) Time: 859.980 ms postgres=# select count(*) from tbl2; count ------- 3 (1 row) Time: 0.420 ms压测
vi test.sql \set id random(1,10000000) select * from exchange_t(1::int8, 0.1::real, :id, now()::timestamp); pgbench -M prepared -n -r -P 1 -f ./test.sql -c 64 -j 64 -T 30 transaction type: ./test.sql scaling factor: 1 query mode: prepared number of clients: 64 number of threads: 64 duration: 30 s number of transactions actually processed: 2970824 latency average = 0.644 ms latency stddev = 0.348 ms tps = 98599.587185 (including connections establishing) tps = 98791.348808 (excluding connections establishing) script statistics: - statement latencies in milliseconds: 0.001 \set id random(1,10000000) 0.644 select * from exchange_t(1::int8, 0.1::real, :id, now()::timestamp);每秒转移9.8万记录，采样法消除冲突后性能惊人。
postgres=# select count(*) from tbl1; count --------- 7029173 (1 row) postgres=# select count(*) from tbl2; count --------- 2970827 (1 row) postgres=# select * from tbl2 limit 10; pk | id | info | crt_time | mod_time --------+---------+------+---------------------------+---------------------------- 329257 | 10 | test | 2017-03-03 16:48:58.86919 | 2017-03-03 16:51:01.261172 107713 | 10 | test | 2017-03-03 16:48:58.86919 | 2017-03-03 16:51:08.012152 360129 | 10 | test | 2017-03-03 16:48:58.86919 | 2017-03-03 16:51:13.969138 61065 | 7513722 | test | 2017-03-03 16:48:58.86919 | 2017-03-03 16:52:44.669893 95337 | 4101700 | test | 2017-03-03 16:48:58.86919 | 2017-03-03 16:52:44.672948 124441 | 7159045 | test | 2017-03-03 16:48:58.86919 | 2017-03-03 16:52:44.673335 87041 | 1868904 | test | 2017-03-03 16:48:58.86919 | 2017-03-03 16:52:44.671536 126617 | 4055074 | test | 2017-03-03 16:48:58.86919 | 2017-03-03 16:52:44.673654 10201 | 3790061 | test | 2017-03-03 16:48:58.86919 | 2017-03-03 16:52:44.673959 191081 | 6663554 | test | 2017-03-03 16:48:58.86919 | 2017-03-03 16:52:44.674014 (10 rows)1. 为了解决高并发的数据随机访问、更新、转移等热点与扫描相似悖论的问题，PostgreSQL 采样接口打开一种很"无耻"的优化之门，让小伙伴们可以开足并发，卯足玛丽开搞。
为什么一个蛋糕，大家都要从一处抢呢，围成一圈，每人在各自的方向挖一勺不是更好么？就好像小时候长辈较我们夹菜，要夹靠近自己这一边的一样。
https://www.postgresql.org/docs/9.6/static/plpgsql-statements.html
https://wiki.postgresql.org/wiki/TABLESAMPLE_Implementation
相关资源：python入门教程(PDF版)