好多时候我主动或者被动参与到一些优化的工作中来。有的时候提升较大，比如我在公安行业时候，有一次开发找到我说，他们一天出一个报表，一次15个小时，忍受不了了。问我能不能优化到一个小时。我接手以后除了索引（不能仅仅指望索引，但是一点不用也不行），总之N个改进建议以后。最终执行的结果是6秒。15小时到6秒，大约9000倍的提升。当时开发吃惊的嘴都合不上了，但是这才是一个数据库应有的效率。不少人误解报表就应该很慢，其实这不一定的。以上这个虽然不是我个人的记录，但是充分体现了优化比起硬件提升的收益之大。不过这里有个前提条件就是开发不折不扣的按照我的思路去做了。如果我的建议和意见，不采纳，不去实施，那一点用也没有。就会形成“可怜夜半虚前席，不问苍生问鬼神。” 的结局。
但是有些系统给了建议也不改，很大程度上是因为，没法改，因为设计的惨不忍睹，如果说改，还不如推翻重来，接受不了或者做不下来。 “高性能是设计出来的”，DBA圈内的至理名言。反过来说在设计糟糕的情况下一切优化都是扯淡。我讲优化从来几乎不讲SQL改写，因为这样的收效不大。我多年工作发现，几乎都是设计问题，甚至是需求问题。这个重要吗？我说重要可能未必大家都认可。多年前帮一个朋友忙，他们公司遇到问题（每周系统都故障至少一次），技术团队最终定位是由于数据库引起的。也是托人打听到我，让我去看看。我看过以后，指出了问题已经改进方法。技术团队明白了问题所在，即可开始修改，有的可能是要改实现方式和逻辑。但是他们天天干到凌晨2-3点，干了一周。（私人小公司，系统不稳定，营收受到较大影响），所以比较认真对待。经过奋战以后，结果是再也没有出过问题，为此特意感谢了我。最后反馈说用户反馈系统快的有点不适应了。
一个系统就看是不是自己的命，刚才这个案例中是因为私人小公司，出了问题损失都是自己的。而我挽救了系统的稳定，等于间接的救了公司的“命”。对于已经给了建议不能改的，那么也没有办法。
那15个小时到6秒是极致吗？显然不是，所谓优化只能在现有的基础上做的最大限度改善。之所以能提升9000倍是设计还不算差，但是如果能按照我的设计的话，那个应该最多2秒就可以了。数据库设计最重要的是数据类型和表的设计。每个项目和场景都是不一样的，但是我见过很多的就是把以前项目的表在这里铺开就用。最后SQL写的特别复杂和低下，那是因为用表去适配需求。而我觉得应该是根据需求来设计表，除非需求一模一样，否则每个项目的表结构都应该不同。表结构设计的差不能用吗？能，只是性能差。性能差不能用吗？能，只是不稳定。不稳定要紧吗？有的要紧，有的不要紧。还是看是不是重视。
我们很多系统故障不是因为网络中断或者硬件损坏（这种极少，如果有，那说明基础环境不稳定，基础环境不稳定的别指望数据库可以解决），基础环境的前提条件要去满足，这些不满足整改起来还是相对容易的。常年亚健康的数据库（负荷高的）就像抵抗力弱的人，一旦有风吹草动就可能生病了。这种系统就要平时不断检查，要做预警，有的时候尽管有预警但是来的太快，几秒钟的时间就已经造成了事故，根本做不出反应。但是免疫力好的（几乎没负荷的数据库），突然来一下十倍，甚至百倍的冲击依然能抵抗住冲击，从而保证系统正常运行，在这种情况下，即使没有来得及做提前预警，无法比用户早感知，但是还是可以平稳度过。
