数据库的一些基础研究和性能探讨（触发器）

一直没有机会使用到触发器，但是在一个偶然的情况下，我在做用户同步和权限删除时我想起了这个功能。

在设计数据库的时候，我往往都走进一个怪圈，可能就是应了一个数据库的前辈所说的：开发数据库的思维和方式不能用开发其他模块的思维方式来做，可惜当时我只是一个后台开发工程师，并没有深刻去了解。现在我发现很多地方在选择哪里该封装，哪里该用那种封装，是视图，函数，存储过程，我都往往会偏向于存储过程，因为这是很接近一个我们平常用java或者python那样封装的方式（虽然数据库的函数更贴切，但是调用来说，存储过程更像我们平时开发的调用习惯）。

我把触发器当作一种被动的存储过程，但是在开发过程中，什么时候使用他呢？来个讲解其作用的引用：

触发器的主要作用是其能够实现由主键和外键所不能保证的复杂的参照完整性和数据的一致性。它能够对数据库中的相关表进行级联修改，强制比CHECK约束更复杂的数据完整性，并自定义操作消息，维护非规范化数据以及比较数据修改前后的状态。

在我使用完毕后看书时，发现不同的数据库的不同版本，对使用触发器来说都有着不同的地方。但是主体来说作为删除用户和一些扣款之类的业务还是挺不多的。

但是从我开发人员的角度来说，触发器有一个缺点就是，假如你发现一个问题是关于触发器的，但是因为它对于你来说是“不显示的”，所以导致我会找bug找很久才找到这里，对于维护来说是一个很大的挑战。这点可以通过对触发器的统一管理。

同时我使用的感觉，在before使用触发器的效果还是不错的，而after的话其实很多情况可以用存储过程替代了。但是我的结论是：慎用，尤其我这种刚涉猎的初哥。

其实使用的优缺点不是我最关心的，最关心就是性能。

因为我这边做的表关联比较复杂，而且涉及到2个完全不同的数据库之间的同步。如果用上了触发器是一个很好的解决方案。但是问题来了，虽然我这里的需求可以异步操作一些，但是因为2个不同的数据库之间还夹着一个我上层语言编写的服务来同步的话，是一个很大的挑战。第一，同步数据的间隔时间，第二就是设计触发器的复杂度。我在设计的过程中，一边用上层语言写好逻辑，然后又写了一个差不多功能的触发器，为了就是对比效率。因为我使用数据库层为了就是提高性能和方便维护，所以我一直在做这个考量。

结果确是慢慢的把大部分功能都交给了存储过程+上层逻辑去做，第一是因为触发器使用是有限制，导致一些我想实现的sql组合不能实现。第二就是其实我算是涉及到2个不同的事务，这个对我设计来说功能影响很大，在做模拟的自动化测试就已经出现了和别的业务同时操作表的冲突问题了。最后唯一一个和性能相关的因素就是在多并发的场景下，我发现大数据量修改和删除时会偶尔出现一些数据库抛出的错误和一些修改失败的情况。无论是并行还是并发的情况都存在的话，这个是我同步设计中最不想看到的结果。

所以最后通过我这个sql初哥的实验和工作的结果来看，我为了准确性和部分性能原因，最终还是选择了以存储过程和上层逻辑为主，在一些并发不高的一对多的场景下用了一小部分的触发器来完成我的需求。