有朋友在后台问上周分享中这张图的关系，在这简单说说，
P.S. 分享链接，
《感悟线上分享》
《技术分享邀请》
这块的上下文，是说我们倡导培养“优化前置”的数据库设计开发思想，道理其实都懂，像隐式转换、不必要的全表扫描，都是可能的风险，但是这些问题，在开发测试阶段，如果背景数据量很小，如果单纯靠白盒测试，可能发现不了任何的问题，功能都是正常的，然而一旦上生产，数据量上来了，就可能直接影响业务的处理能力，非常被动。
对这类的问题，无论是改数据库的结构定义，还是做程序改造，如果是在投产阶段发现的，严格意义上，就需要各种测试、跑上线的流程、上线窗口的操作、验证测试等环节，都得有个过程，人力、物力，时间，都得消耗，成本很高。往往这种问题，并不难改，加个函数、改个类型，如果这个问题是在设计开发测试阶段发现的，可能放在某个开发迭代中就可以解决，成本很低，但是相对来讲，收益就会很高，典型的事半功倍。
对这类问题的解决应该有两个路径，
- 开发人员在编码过程中，要提前注意这些问题，有意识地避免可能的风险。要做到这个，要么是开发人员的经验，这个因人而异，不可控，要么就是有技术规范，参照规范编码，显然只是有规范，不能做到闭环，还得有规范验证的手段，参考规范-验证规范执行-反馈更新，形成闭环，才可能让代码尽可能地向规范靠前，避免潜在问题。
- 通过技术手段，主动挖掘风险，像代码扫描工具(《阿里的Java开发规范插件验证》)、数据库审核平台，甚至是代码review，这些都是为了主动发现编码、数据库结构定义中的问题，将他们和流水线、软件开发过程相结合，发挥更大的作用，是我们所要面临的问题。
“优化前置”的思想，其实不仅针对数据库开发，对于其他的领域，都是适用的，道理显而易见，但是实操起来，就未必能做到了，这个不是一蹴而就的事情。
近期更新的文章：
《v$视图存储SQL的bug》
《RPO和RTO是什么？》
《最近碰到的几个问题》
《Linux的inode是什么？》
《小白学习MySQL – InnoDB支持optimize table？》
文章分类和索引：
《公众号800篇文章分类和索引》
声明：文中观点不代表本站立场。本文传送门：https://eyangzhen.com/419925.html
