今天有人让我帮忙看一个系统，检查一下。因为这个系统暂时无人专职维护。我托人拿到后台日志，我看到有个系统的SQL是排名靠前的TOP-SQL，每天执行6000多次，每次12秒。把他找出来一看就是全表。从技术的角度，我们当然可以告诉他，应该加一个过滤条件。然后找到开发，告诉他你看我给你这样的改进建议。开发拿着这个意见回去说评估一下。
下午评估结果出来了，说理论上这样改可以。不过他们查下来这个SQL不应该运行。因为这个不用了，很久以前有个场景：相关数据推送到微信公众号和移动app，推送是一个定时任务（定时是10秒）完成的。后来APP，停用了。 但是 仅停用了调用app的推送方法， 未停用 定时任务，导致查询方法一直在运行。所以打算停止这个定时任务。
这样做本身没有问题。其实优化的极致就是不做。我这里说的不做，不是不做优化。而是将待优化的SQL直接下线。SQL可以从10分钟优化到1毫秒，但是有什么比优化到0秒更快的吗？
另外我展开一下反思，这个功能如果不下线，看着原来的设计。10秒一次定时，结果他运行一次12秒。根本执行不完。所以感觉即使不下线这个都没法正常使用。也恰好是这个没人用，才没被发现。这种场景我回想起我公安时候，开发做了一个功能，半小时检查一下设备状态。结果开发做出来的结果是半小时执行一次，一次运行不止半小时。结果永远出不了结果。后来我给他做了一个存储过程5秒出结果，演示给他后，我说按照我这样来写你的程序。开发说，我还写什么程序啊。我直接调你的存储过程出结果吧。
这里又引申出一个话题，存储过程。很多开发喜欢写存储过程，也有很多开发不喜欢存储过程。 喜欢的理由是快速实现功能，不喜欢的理由是不好调试，不好管理，性能低。我本人对存储过程不是喜欢也不是讨厌。不过要说明的是存储过程是可以调试的、也很好管理、更加不存在性能低下一说。我们平时见到的存储过程一般如果很慢的都是写的有问题，写的又多又长。这其实是本身开发写的不好，写的好的是没有任何问题的。比如我写存储过程，一般不超过10行，超过10行的绝对是设计或者思路有问题。基本就是要错的节奏，那是不好管理了。但是如果5行就解决问题，我不信管理不好。
有人说Oracle重，MySQL轻量。其实我也看到过有人在MySQL上10表关联ERP（这绝对是有问题的），我也看到过在Oracle上简明扼要的简单SQL。所以数据库没有轻重之分，只有用的对不对。看你怎么样。
张无忌用木剑打赢了倚天剑，你能说倚天剑不行吗？我又要说一句老话了，一般TB基本的企业，需求合理，SQL设计和实现的好点，要什么hadoop？
