作为DBA总是会有现场的救火工作，而如果尽可能早一些介入需求，设计，开发阶段，可能就会杜绝很多潜在的性能问题。很多问题都是如此，都是逐步积累，最终在某一个阶段会集中爆发出来。今天看老盖的感慨，前十年跟全表扫描斗争，后十年跟隐式转换斗争，几代DBA大约都会面临这样的事情，想想真是蛮有意思。
    而且前些天和领导在聊天的时候，我说现在优化没啥动力，一方面业务的使用量是有富余的，一个SQL从10秒优化到5秒，好像也没什么特别的成就 感，说句俏皮的话，可能是你比较喜欢折腾。另一方面绝大多数的业务使用数据库的都是很基础的功能，就是把数据库当做一个黑盒的存储，先不说这种观点对与不对，越是如此，越会引入更多的问题。到了后期，就好像问题到了晚期，大量的表连接，复杂的连接关系和臃肿的表数据甚至过度设计，分析起来都是可以改进的地方，但是落地的时候很可能是DBA得向业务和开发妥协，或者相反，哪种情况都会无形引入很多的时间和资源成本。最近这种感触尤其深刻。        开发的同学前几天问我一个问题，是关于JOB的权限设置，其实JOB本身没有其它的权限，需要考虑引用的对象的权限，设置的触发时间，频率等，鉴于线上环境的复杂性，可能开发同学介入分配会有一些难度，在讨论之后我只好做了妥协，就是我来处理这些权限的问题。开发在最后提交的时候，也和我简单做了确认，这个时候我大体明白了他们的需求。而开发的同事也顺便问了下我，说有一个操作想让我也评估一下性能，大体的思路就是开发通过在线业务会得到一些回流的客户数据，这些是增量数据。平均每天就是几千条数据，目前他们的设想就是在每天的零点开始批量处理，把表里的一个字段统一修改，语句类似下面的形式：
update test_customer set enabled=‘Y’;
commit;
    如果按照数据量来看似乎也没什么，目前来看性能上是完全可以接受的，但是经过确认，这个表不是中继表，临时表。里面的数据是逐步积累的，也就意味着表里的数据量会越来越大，那么就会在某一个阶段成为瓶颈，如果表里的数据成百万，上千万，这样的操作是很有问题的。和这位同学的交流，他们也感觉这种方式可能有问题，其实他的本意是想找我确认下，数据量多大的情况下可能会导致问题，是几千条，几万条还是几百万条这样的。当然我马上矫正了他的观点，这个没有一个完全的基准，可能有的同学说，加上一个时间字段过滤，取得增量数据，每天增量几千条数据的DML还是完全可以接受的，但是和开发的交流发现，因为业务在初期设计的时候就没有考虑到这样的限制，所以现在添加起来会有一些难度，而且代码已经到了最后的审核和提交阶段。所以目前来看这个问题就有两种走向，开发同学无法改动，坚持上线，后期发现问题，继续救火。还有一种就是按照增量的方式来改进，只修改增量的数据，这样始终是保持在一个较小的数据范围，可选用的方式就多了，比如添加时间字段的索引，比如设计分区表，按照分区来更新等。开发的同学有一些犹豫，但是还得进一步确认一下。      大概在下午的时候，他们给我反馈，经过讨论，决定取消那个JOB,其实可以完全通过其他的方式来达到这种效果，他们重新设计了逻辑，把定时的批量变更改为了实时的变更，做了这些改进之后和调整之后，还是可以按照原计划上线了，看到这种结果，着实让人欣慰。一方面我们没有因为这件事情扯皮，这种事情在任何情况下都可以有多种妥协的情况，于情于理怎么解释都似乎说得通，另外他们是认真去考虑这件事情的，了解了隐患而及时处理，没有带着敷衍的态度，这点确实值得我们学习。
    所以调需重于一切，把潜在的问题及时扼杀在摇篮之中，会极大的减少错误放大效应的影响。