面对下不去手的代码怎么办
不知道各位有没有这种经历，看到一个SQL写的特别复杂，十几个表关联（如今的我已经见怪不怪了，深知这是为什么。在一开始就没有重视的情况下，这是必然的）。很多学员或者朋友发我的SQL打开一看，真想直接关闭。面对这些下不去手的，我通常也只能闭上眼了。
别说复杂的SQL，有的时候遇到极端问题即使简单的SQL出问题也要检查半天。数据库是太复杂了。但是绝大多数企业的信息化工作中不太重视这块，一般是重研发轻运维、而数据库排在运维之后，算是轻之又轻的。甚至把Redis、elasticsearch这些NoSQL数据库都归到中间件部分去，也没有专职的数据库专业人员。让一般的运维人员来维护数据库。其结果就是会出现上述问题。
10多年前，我做数据库维护，我觉得DBA（始终强调一下这个A不仅仅是administrator，还是analyzer和architect），应该是指导开发怎么实现。后来我发现这个其实晚了，应该是指导开发设计、甚至是自己来设计，然后告诉开发如何实现。现在我发现其实这个也是晚了，要和业务说你不要这样提需求，而应该这样提需求。Oracle18C开始都开始自治数据库了（现在不少数据库也在向Oracle对标）。那么DBA做什么？其实就是做我刚才说的，和业务的拉扯以及主导设计，告知开发怎么去做。否则就是出现这种下不去手的代码。
每次我给求助的人的解决方案，都是要改动一些东西，有些是伤筋动骨的，也有的是重构建议。但是即使是小的改动，在开发看来代价也很大。这种问题上升到领导层面也很难抉择。
不过我这几天看到一句话： 发现错误马上改进，再大的代价都是最小的代价。顿时治愈了，说的太对了。因为现在不改，在错误的继续做下去，将来代价还要大。
收尾讲个故事：以前就有开发找我说：“我们实在没有办法了，决定采用你的方案”。其实也就是说代价大不大其实不重要，只是没被逼到那个非改不可的地步。当计算资源已经无法承受烂SQL而且无法补充了，那么这个时候代价大不大就不重要了。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/637517/viewspace-2951956/ ，如需转载，请注明出处，否则将追究法律责任。
