31 点经验分享与吐槽

本来在家安心的写 golibs,写到数据库这块时想写个备注，可能有些东西累积已经太久，然后就一发不可收拾，写了很多。放在代码仓库已经不合适了，删了又可惜，就放在这吧。

1. 如果要用数据库中间件，个人看目前 小米的 Gaea 可能是相对更成熟的。

但还是建议先在非核心系统试用，否则一次踩坑，可能足以致命

2. 见过在 Go 框架中使用 Java 那套手写 xml 配置管理 SQL 的方案。很难理解，

不同语言的开发理念是不同的，一定要这样南橘北枳吗？

3. SQLHooks 是个好东西，但最好多测试，各方面评估再确定用不用。否

则还是老老实实打日志吧

4. 现在的研发更喜欢在数据库前面去解决问题。作为一个很多年前曾经做过几年 DBA 的人来说，

他们可能严重低估或者说不太了解数据库本身强悍的能力，以及这么多年实操下的解决方案。

对于绝大多数没有 BAT 那种量级处理的系统来说，评估下，在很多情况下，适当合理的利用

好数据库解决问题，可能是一个性价比更高的方案。

5. 在产线见过无数个只求快速完成需求，没有数据库性能概念的小伙，用无数种方法把数据库给搞死。

拜托！以后招人别老考些造卫星的算法，适当多增加些数据库相关的题目吧。

因为大部份的岗位 CURD 更有可能是他们的日常。

6. 数据库主备库间的读写延迟，引发的后果是令人恶心的，一不留神就会中招。在业务系统中，

不考虑这个问题，对一些敏感数据，纯纯的相信备库的数据，等着被业务部门或用户投诉吧。

至于方案，接触过的方案中，aws 的 Aurora 想从存储层面的强一致性来解决这个问题，

但它对机器的要求相对比较高，是一个比较花钱的方案。

NewSQL 类型 DB 没上过产线,不发表意见。相对来说，其实在代码层处理可能更实在。

7. NoSQL 是个好东西，至少我在 Redis/influxDB.图数据库（风控）等上深深受益.但问题在于，

很多研发是管杀不管埋，就是其实只是因为某个功能而用了某个库。但数据库只是大致有个模糊了解。

后面的部署运维，异常问题或瓶颈处理一概不知。搞毛呢，上产线后这些都会是随时可能爆的雷。

8. 有些公司在研发的要求下，把数据库日志开放给研发随便看，日志里面帐户，密码，用户个人信息等满天飞。当你碰上某些相对严格的审计（如支付或安全相关），碰上某些职业素养不高的人时，后果可能会很可怕。

9. SQL 注入是可以避免的，但如果一个公司的研发，在 sql 开发上各显神通，各种封装和解决方案满天飞，

没有一套解决方案（审计，安全等）和机制时，SQL 注入会不可避免的发生。

10. 可能不同的人对 sql 如慢查询(耗时几秒)的定义是不同的，对其所影响的后果是有差异的，对 sql 优化的优先级是很低的，所以可能事故报告是不可避免的。

11. 你如果对于哪些表数据增长最快，哪些表是"胖子"表占的空间最多，最常用但性能很差的查询是哪些都不了解，等着爆雷吧。

12.因为公司实力的原因，可能同一个数据库主库对应的多个备库，机器配置在不同阶段是不一样的。不说清楚。就不要怪研发把某些库拖死。最后的最后，某些云厂商的数据库会被要求强制升级，可能会在未来某天突然给你致命一击，直接 KO！

13. 云厂商的数据库是有一定概率自动重启的，因为底层的硬件故障或碰到他们不负责的运维。

14. 是先设计类，然后代码自动化生成表，还是先做好表设计，再写代码？ 这是个问题。

15. 有些研发想，真是管得太严了，都不给我数据库处理权限，还是我自己偷偷写几个接口留个后门，用于查数据和做特殊处理吧。这样就不用麻烦别人，反正是内部服务，没啥事的。外部服务的话我自己加个认证就好。这是一个不愿麻烦同事的善良的人所想到的办法。能说啥好呢？

16. 做代码 Review 时发现有同事在代码中写了条超长的 SQL。 问为什么这样写？他说我的 SQL 越长，

就代表我的 SQL 能力越强啊。竞有不少人有类似想法，你也是这样的看法吗？

17. 这里"select *"就可以了，省事。这里可以用跨库查询，更方便啊。有经验的前辈在指点新人。 呵......

18. 某些同样的通用字段在不同的团队都自己的理解和习惯。如是用,0 或 1，1 或 0，true 或 false 来表删除?

时间是用 datatime? Unix Timestamp?类似的字段很多。直到对接，碰撞时才发现这可能是个大问题。

不能怪研发，毕竟有开发规范，有数据库规范，但这些规范很难定到全公司啊，只有所谓的约定俗成。

但团队多了后约定俗成的约定连 P 都不是。

19. 现在的云服务基本都能满足要求，也同样都有不稳定的时候，所以能不能有及时可靠的技术服务有时更重要，价格反而不是那么决定性的。但从财务角度看可能会不同。

20. 千万不要被云厂商的 ppt 所迷惑，而轻易当了他们新产品的小白老鼠，ppt 上的"理想"与现实，可能是有差距的，而结果却要由你来承担。

21. 出了事故，你可能才会发现，在各种自证逼对方承认是他们的责任后。云厂商协议上的赔偿公式是那么的刺眼，按它的赔偿公式算出来的赔偿金额低的让人吃惊。不信你去翻翻。

22. 代码屎山是不可避免的。但从长远看，是没什么问题的。存在即合理，这样一直没清理过的屎山重要性可能很低，可能过几年就没了。真正有用的系统要么早被人盯着精心打理清理完毕，要么早就被重构了。

23. 你可能永远也不知道用户会在你的系统里输入什么有想象力的数据，不按常理出牌的调皮同事有很多。

所以有条件记得定时扫描，不然很有可能在各种审计审查中中招，解释很麻烦的。

24. 分布式事务其实很危险，建议最好能不搞就不搞

25. 数据库的表模型，团队成员应当人手一份，可以用 PowerDesigner 或 pdmaner 逆向导出

26. 不要轻易相信来自测试环境数据库的结果，有时误差是很大的，这块能做得很好的没几个公司

27. 对于强依赖数据库的服务，如果以影响性能为名拿掉分布式锁，前面没有反爬，没有防雪崩，不知道设流控值，连接池用了夸张的最大连接数，不会用缓存，你可能还没入行。但这又是现状，因为有很多工作被写框架的团队和运维给做了，所以这些人不需要接触，根本没概念。换家公司就很难写出稳定的服务了。

28. 危险不止来自于前方，也要保护后后背，那些各种原因需要从数据库中同步或批量搞出数据的服务，

可能是"猪队友"在弄。

29. 不要低估来自内部运营系统的破坏力，这年头，连少儿编程都普及了，哪几个运营或产品不会点 python

30. 不要高估部分研发的素质或经验与运营同学的耐心，当一个大数据量查询一直没出结果时，狂点查询按纽是一般人的选择，然后后果可能很严重。另外还有万能查询，不能命中索引也很危险。多少年了这些问题一直都在。

31. 如果评估可以，建议对数据库配置一个对高危险 process 进程检查和自动化 kill，可能能救下你整组人的绩效

只代表个人意见，看到的当个参考就好。