本文只从逻辑上进行说明，并不从物理上进行说明。物理结构不在本文讨论范围之内。
我们的资源有:CPU,内存,IO
我们的应用程序分以下三层:表现层,业务逻辑层,数据操作层
优化其实是对以上所说的进行优化。优化前必须明确以下几点：原有的应用程序设计不能受到破坏；原有的需求不得更改；应用程序的可维性不得降低。至于为什么，刚才写的草稿说了，没有保存，懒得再写
。原因大家也知道，感觉写了会浪费
。直接进入主题：分为数据库问题与应用程序问题。
假设数据库出现问题，这个时候我们知道用户在进行什么样的操作。打开SQL监视器，进行用户操作，然后在SQL监视器里面定位问题所在。SQL问题所在分为SQL语句以及这条语句里面对资源所产生的消耗。把SQL语句拿到SQL管理器进行查询分析，这样你就能定位到语句中什么地方产生问题，然后对表结构（聚集索引以及非聚集索引）以及SQL语句进行调整。简单吧，而事实上就是这么简单的。
假设应用程序出现问题，这个时候我们同样也知道用户在进行什么样的操作。问题是在于有没有工具能监视到所在的代码行。有的，05以及其后的版本据我所知是有的。另外推荐另外一个工具：ants profile。使用这个工具外加一个并发仿真模拟就能很快找到问题所在。另外你还可以使用性能计数器（这个只能查到到一些，但不能真正定位）。
看完了以上所说，你可能会问，优化咋这么简单呢？？？？？？？？？？而事实上就是这么简单的，难道真的不好用吗？？？？而事实上简单是最好用，最实用的。
在这里我在网上看了很多优化的文章，感觉写的非常详细具体，也非常不错，只不过没有说明如何定位问题的所在。但是在商业环境下并不适合，因为商业环境下是需要以最低的成本创造出最高的商业价值。从一大堆代码去慢慢找吧，累死人，而并未能解决问题所在。而从商业价值的角度上看，这无疑是个失败的。为什么呢？？？？？？？原因很简单，他们并没有快速找出问题对象的所在，并且迅速的解决问题。我的观点是：快速把主要问题解决了，大家去喝茶，聊天，学技术，不要把时间用在一些小点子上，从结构上的优化性能远高于每一行代码优化的性能，不要最后在性能问题上搞得上面郁闷，下面更加郁闷。