多余，防君子不防小人，但做外挂的哪有君子？

通知结束用 context，等待结束用 wait group

https://play.golang.org/p/GGOY8mugpw4

不能，谁叫你不用 lvm

写代码把老数据迁移就行了
迁移完就删除

状态其实两种就够了，好友和拉黑
没有关系时，没有记录
如果一方发起申请，那插入一条 (friend, null)，如果另一方同意，就变成 (friend, friend)
这样如果一方发起申请，另一方也同时发起申请，那结果也是 (friend, friend)
只有 (friend, friend) 这种状态，才是好友状态
任何一方都可以解除好友状态，变成 (friend, null) 或者 (null, friend) 或者 (null, null)，这些都不是好友状态了
拉黑就是将 friend 改成 block，变成 (friend, block) 或者 (block, friend) 或者 (block, block)
这样就完全成了单表单行的操作，不存在锁的问题了
这样还能增加其他状态，例如好友之上的特别关注等等

不用加锁，就默认的 read committed 下，在事务最后看有没有好友关系，如果有，就 rollback。

其实单表实现是最好的，用两个字段分别表示互相的态度（想要建立关系，确认建立关系，拉黑），因为各种态度是互斥的，所以可以这样做。这样可以很容易表示出“a 想加 b 为好友，但 b 已经拉黑了 a”这种状态。像你那样设计，遇到这种情况，你除了要锁好友表，还要锁拉黑表吧？一张表，就完全没有这些问题。至于时间和文本，完全可以合并使用一些字段。例如申请加好友的信息，和对好友的备注，可以用同一个字段。既然叫做 relationship，那就用这个表表示关系的变化，完全可行。

实体清单警告

A 可以少一次移动

或者直接输入 )

你倒是做出来啊。

不走全表，是没可能算出结果的，你怎么优化都不能违背基本逻辑。
可以给 date 加范围条件，如果业务允许的话。

@imherer @> 加上索引，是效率最高的。你这个又要 join 又要转换成 text，可能会出现效率很低的执行计划。

@imherer 看后面的，用 @>

&& 是用在数组类型的，不是 jsonb 类型

@randm @> 可以用在 array 上

看错了，json 要用 @>

select category @> '11'::jsonb

where category && array[11]

@misaka19000 自我审查习惯了