mysql - 触发器的实际使用场景, 可能也就是这个了, 一起讨论还有没有别的

Question

触发器的实际使用场景大体说来就是帮你方便的迁移数据, 不过最好不要和业务紧密结合, 因为一个事务的的一部分在java那边, 另另一部分在触发器中是无法很方便的调试/排查/维护的, 唯有一个场景, 就是不想物理删数...

大家讲道理 · Answer

首先关于触发器，很多大公司是禁止使用的，一是可移植性差，二是影响性能，这也是我强烈主张的。

然后着重讨论下非物理删除的情况吧。碰到有唯一键约束并且有is_delete这种列的表，确实特别蛋疼的。我在项目中是这么处理的，假设用户表user有这么几列：

插入时，如果唯一键冲突，那就查一下有没有被删掉的同名用户：

SELECT id FROM user WHERE username = ? AND is_delete = 1

有同名的话(并且得到了id)做一个UPDATE操作，就当是恢复删除了：

UPDATE user SET ..., is_delete = 0 WHERE id = ?

然后蛋疼的问题就来了，既然用户有删除的需求(说实话这种需求是不多见的)，也就有改用户名的需求。改用户名遇到主键冲突，并且已存在的用户是已被逻辑删除的，那么你到底是让他改还是不让他改呢？

权宜之计是把唯一键也做成“非物理”的，每次创建用户前都去查一下，查到没有被删除的同名用户，就允许创建，改名也一样。不过这种操作可能要做成事务了，因为在并发高的情况下，完全可能SELECT的时候还没重名，但INSERT就重名了。

大家讲道理 · Answer

楼上的问题
"改用户名遇到主键冲突，并且已存在的用户是已被逻辑删除的，那么你到底是让他改还是不让他改呢？"
有个办法以前在小项目使用过，不知道大的项目可不可行。
每个表都使用自增ID，主键的约束使用主键+"is_delete" 的约束。