优化你的系统（一）

前几天和几个朋友聊天,提到一些关于SQL Server方面的一些问题，褒贬不一，他们也碰到了一些性能问题，我给了一些个人的建议，也不知道是否奏效。

Q ：SQL Server 2000 的数据库压力很大，CPU 和内存老不够，但是调整的时间又有限，应该如何解决？

从表面来看，无疑是程序问题，但是大多时候碰到这种情况是比较冤枉的

1．程序不是自己写的

2．在线系统已经没有足够的时间去调整程序

3．数据库设计有些致命的问题

4．…..

不熟悉、不能和不足够时间，我想问题大抵如此吧，简单的建议如下

1．超过2G内存的机器，请确定是否在启动参数中加入了 /PAE /3GB选项

2．是否在组策略中给运行SQL Server的帐号指派了使用AWE的权限，假若没有，查阅相关文档启用

3．在SQL Server中启用AWE，需要通过sp_configure命令来做

4．将内存调整成固定内存，2005会好一点，如果是2000，请务必检查启动日志，设置太高的最小内存会有可能实效

5．这些都做了，发现还是有问题，升级到SQL Server 2005。

这些建议都是治标不治本的，不过或许能够帮助适当缓解数据库的压力，内存管理不当会让SQL Server晕菜的。

如果还是有问题，如果还是不熟悉SQL Server ，不能修改程序，更加没有足够的时间，那么可以考虑做下面的一些工作

1．使用SQL Profiler，抓出执行最长的这些语句，然后看看那些where之后的字段是否建立了索引，在该建立索引的地方建立索引

2．如果发现这个是比较复杂或者麻烦的事情，使用SQL优化向导，从某种意义上，这个小工具还是可以帮助解决问题的，听天由命吧，能优化多少算多少

3．如果这个也没辙了，看看那些执行效率比较低的代码是否是存储过程，通过一些工具，如SQL Expert，来帮助你做一些SQL优化，然后乖乖地拷贝回去

4．如果发现是插入语句过慢，那么有可能是吃撑了，也就是你的索引建多了，适当看看语句的情况，该去则去吧。

如果发 现还是应用事件探查器优化SQL Server系统》，利用read80trace来帮助你分析日志吧，通过此能够找到一些通过你刚才方法无法找到的未建立索引，苏先生已经讲述的非常详细，我也不去COPY了。多废话几句：不奏效，那么推荐去阅读苏有全先生的《

1．关键集中在查询时间占据最多的语句，基本上你可以理解为这是整体数据库系统消耗的百分比

2．另外可以适当看看I/O占有最大的语句，可能适当的磁盘系统优化也能够帮你解决问题

因为这个问题回答的是希望能够最简单快速解决部分问题的情况，一些比较复杂的情况和调整就不去做了，虽然时日不长，不过一时半会应该可以撑过去。

Q ：数据库中有某个表特别大，导致查询性能比较低，应该如何解决？

这个问题是去参加TechED的时候路上和一个朋友讨论CSDN的Blog而引发的，虽然我阅读过部分.Text的代码，但是了解依旧有限，只是从个人的角度给出了一些建议

1．如果这个表包括了大量的可空字段、频繁更新的字段（如点击数）、大文本（文章内容），再加上这个表超过10万条记录，差不多剩下的日子就是等死了，那么这个时候就是分拆。

a) 将文章和评论拆开（这点CSDN似乎很多年前就干了）

b) 将频繁更新的字段拆到另外一个表，虽然我们可以说主表ID建立了聚集索引，但是不管如何都存在读写锁的代价

c) 大文本字段 务必拆解到另外一个表上，因为不管如何，你让一个表文件几十个G对系统没有任何好处

d) 另外不要将统计相关的信息和大文本放在同一个数据文件

e) 如果磁盘读些速率还有区别，频繁更新的表所在的数据文件放在高速磁盘上

2．尽可能升级到2005，从而利用其分区功能

3．根据业务调整分区规则，一般来说，按照年/月来归档就足够了，详细的分区使用可以查阅相关的帮助

4．大多文本内容是可以缓存的，如果非要使用MemCached，尽量不要使用Windows版本的，而是假设在Linux上

5．更加简单的做法是建立一个自己的CacheServer，不需要太多的工作，使用Remoting提供服务就可以了，协议当然是TCP，而后台可以利用HttpRuntime.Cache和文件来实现双缓冲，如果担心文件读写在多线程的情况下会产生比较大的压力，可以使用异步I/O来解决

6．维护一个自己的缓存过期列表，尽量不工作，而是通过时间戳判断来决定是否超时

7．缓存引发的另外一个问题是缓存超时或者对象更新（如文章更新）之后的对象移除，可以利用MSMQ异步通知缓存系统删除缓存

8．当然了，如果只有单台Web Server，放在进程内是更加合理的

另外，如果可以静态化的，尽可能静态化，因为静态HTML能够充分利用windows 2003的kernel mode cache