关于postgresql行锁的信息

为什么使用postgresql skip locked加锁失败

是因为同时更新事物失误。

通常在数据库中最小粒度的锁是行锁，当一个事务正在更新某条记录时，另一个事务如果要更新同一条记录（或者申请这一条记录的锁），则必须等待锁释放。

通常持锁的时间需要保持到事务结束，也就是说，如果一个长事务持有了某条记录的锁，其他会话要持有这条记录的锁，可能要等很久。

相关问答

Q1: PostgreSQL 锁表解决

1、查询正在运行的进程

2、查看等待中的进程

3、释放锁定

Q2: PostgreSQL 中 sequence 的用法

sequence 是 pg 自带的高效的自增id工具（也叫序列）。sequence 使用了轻量级锁的方式来做到高效自增id的，所以会比 UPDATE 行锁快。sequence 的返回数据类型默认是64位的整数，pg 10 可以自定 smallint, integer 或者是 bigint。

sequence 是可以保证自增数据不重复的，也就是说每次自增后都会持久化保存，那么为了继续提高性能，可以加上 CACHE 参数（默认为1），每个进程（连接）可以缓存一个子序列在当前进程内存里面，当子序列用完了才会去原序列取新的子序列。

这个用个例子简单说一下，创建 sequence temp_seq3 时用了 CACHE 10，A session 可以获取到的值是 1...10，B session 可以获取到的值是 11...20，那么获取顺序可能是 (A, A, B, A)，返回值是 (1, 2, 11, 3)，这个不是严格自增的序列，但可以保证回次返回都是唯一的，用了 CYCLE 参数的除外。

根据文档和源码( link 第80行)，缓存在内存里面的最大值(cached)是每个进程都不一样的，所以如果要求严格自增的服务不能用 CACHE。

这里写三种用 pg 做自增id的方式

测试命令，在 MacOS 上用 docker 开一个 pg 在里面运行一下 pgbench 脚本，其中 sql.sql 的内容替换成对应的压测脚本。

TPS: 986

TPS: 7332

TPS: 7451

看看微信的分布式id生成器，原理都差不多，"实际应用中每次提升的步长为10000" = "CACHE 10000"。 link

以上优化已经是用在友好速搭电商系统的订单号和优惠券号生成服务中，为商家提供更快更可靠的服务。