前几天和几个朋友聊天,提到一些关于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． 如果发现是插入语句过慢，那么有可能是吃撑了，也就是你的索引建多了，适当看看语句的情况，该去则去吧。
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
发表于 @ 2007年12月25日 20:40:00|评论(loading...)|编辑