本来在家安心的写 golibs,写到数据库这块时想写个备注，可能有些东西累积已经太久，然后就一发不可收拾，写了很多。放在代码仓库已经不合适了，删了又可惜，就放在这吧。
-
如果要用数据库中间件，个人看目前 小米的 Gaea 可能是相对更成熟的。但还是建议先在非核心系统试用，否则一次踩坑，可能足以致命
-
见过在 Go 框架中使用 Java 那套手写 xml 配置管理 SQL 的方案。很难理解，不同语言的开发理念是不同的，一定要这样南橘北枳吗？
-
SQLHooks 是个好东西，但最好多测试，各方面评估再确定用不用。否则还是老老实实打日志吧
-
现在的研发更喜欢在数据库前面去解决问题。作为一个很多年前曾经做过几年 DBA 的人来说，他们可能严重低估或者说不太了解数据库本身强悍的能力，以及这么多年实操下的解决方案。对于绝大多数没有 BAT 那种量级处理的系统来说，评估下，在很多情况下，适当合理的利用好数据库解决问题，可能是一个性价比更高的方案。
-
在产线见过无数个只求快速完成需求，没有数据库性能概念的小伙，用无数种方法把数据库给搞死。拜托！以后招人别老考些造卫星的算法，适当多增加些数据库相关的题目吧。因为大部份的岗位 CURD 更有可能是他们的日常。
-
数据库主备库间的读写延迟，引发的后果是令人恶心的，一不留神就会中招。在业务系统中，不考虑这个问题，对一些敏感数据，纯纯的相信备库的数据，等着被业务部门或用户投诉吧。至于方案，接触过的方案中，aws 的 Aurora 想从存储层面的强一致性来解决这个问题，但它对机器的要求相对比较高，是一个比较花钱的方案。NewSQL 类型 DB 没上过产线,不发表意见。相对来说，其实在代码层处理可能更实在。
-
NoSQL 是个好东西，至少我在 Redis/influxDB.图数据库（风控）等上深深受益.但问题在于，很多研发是管杀不管埋，就是其实只是因为某个功能而用了某个库。但数据库只是大致有个模糊了解。后面的部署运维，异常问题或瓶颈处理一概不知。搞毛呢，上产线后这些都会是随时可能爆的雷。
-
有些公司在研发的要求下，把数据库日志开放给研发随便看，日志里面帐户，密码，用户个人信息等满天飞。当你碰上某些相对严格的审计（如支付或安全相关），碰上某些职业素养不高的人时，后果可能会很可怕。
-
SQL 注入是可以避免的，但如果一个公司的研发，在 sql 开发上各显神通，各种封装和解决方案满天飞，没有一套解决方案（审计，安全等）和机制时，SQL 注入会不可避免的发生。
-
可能不同的人对 sql 如慢查询(耗时几秒)的定义是不同的，对其所影响的后果是有差异的，对 sql 优化的优先级是很低的，所以可能事故报告是不可避免的。
-
你如果对于哪些表数据增长最快，哪些表是"胖子"表占的空间最多，最常用但性能很差的查询是哪些都不了解，等着爆雷吧。
-
.因为公司实力的原因，可能同一个数据库主库对应的多个备库，机器配置在不同阶段是不一样的。不说清楚。就不要怪研发把某些库拖死。最后的最后，某些云厂商的数据库会被要求强制升级，可能会在未来某天突然给你致命一击，直接 KO！
-
云厂商的数据库是有一定概率自动重启的，因为底层的硬件故障或碰到他们不负责的运维。
-
是先设计类，然后代码自动化生成表，还是先做好表设计，再写代码？ 这是个问题。
-
有些研发想，真是管得太严了，都不给我数据库处理权限，还是我自己偷偷写几个接口留个后门，用于查数据和做特殊处理吧。这样就不用麻烦别人，反正是内部服务，没啥事的。外部服务的话我自己加个认证就好。这是一个不愿麻烦同事的善良的人所想到的办法。能说啥好呢？
-
做代码 Review 时发现有同事在代码中写了条超长的 SQL。 问为什么这样写？他说我的 SQL 越长，就代表我的 SQL 能力越强啊。竞有不少人有类似想法，你也是这样的看法吗？
-
这里"select *"就可以了，省事。这里可以用跨库查询，更方便啊。有经验的前辈在指点新人。 呵......
-
某些同样的通用字段在不同的团队都自己的理解和习惯。如是用,0 或 1，1 或 0，true 或 false 来表删除?时间是用 datatime? Unix Timestamp?类似的字段很多。直到对接，碰撞时才发现这可能是个大问题。不能怪研发，毕竟有开发规范，有数据库规范，但这些规范很难定到全公司啊，只有所谓的约定俗成。但团队多了后约定俗成的约定连 P 都不是。
-
现在的云服务基本都能满足要求，也同样都有不稳定的时候，所以能不能有及时可靠的技术服务有时更重要，价格反而不是那么决定性的。但从财务角度看可能会不同。
-
千万不要被云厂商的 ppt 所迷惑，而轻易当了他们新产品的小白老鼠，ppt 上的"理想"与现实，可能是有差距的，而结果却要由你来承担。
-
出了事故，你可能才会发现，在各种自证逼对方承认是他们的责任后。云厂商协议上的赔偿公式是那么的刺眼，按它的赔偿公式算出来的赔偿金额低的让人吃惊。不信你去翻翻。
-
代码屎山是不可避免的。但从长远看，是没什么问题的。存在即合理，这样一直没清理过的屎山重要性可能很低，可能过几年就没了。真正有用的系统要么早被人盯着精心打理清理完毕，要么早就被重构了。
-
你可能永远也不知道用户会在你的系统里输入什么有想象力的数据，不按常理出牌的调皮同事有很多。所以有条件记得定时扫描，不然很有可能在各种审计审查中中招，解释很麻烦的。
-
分布式事务其实很危险，建议最好能不搞就不搞
-
数据库的表模型，团队成员应当人手一份，可以用 PowerDesigner 或 pdmaner 逆向导出
-
不要轻易相信来自测试环境数据库的结果，有时误差是很大的，这块能做得很好的没几个公司
-
对于强依赖数据库的服务，如果以影响性能为名拿掉分布式锁，前面没有反爬，没有防雪崩，不知道设流控值，连接池用了夸张的最大连接数，不会用缓存，你可能还没入行。
-
危险不止来自于前方，也要保护后后背，那些各种原因需要从数据库中同步或批量搞出数据的服务，可能是"猪队友"在弄。
-
不要低估来自内部运营系统的破坏力，这年头，连少儿编程都普及了，哪几个运营或产品不会点 python
-
不要高估部分研发的素质或经验与运营同学的耐心，当一个大数据量查询一直没出结果时，狂点查询按纽是一般人的选择，然后后果可能很严重。另外还有万能查询，不能命中索引也很危险。多少年了这些问题一直都在。
-
如果评估可以，建议对数据库配置一个对高危险 process 进程检查和自动化 kill，可能能救下你整组人的绩效
只代表个人意见，看到的当个参考就好。
扫一扫
1697
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
