前几天和几个朋友聊天,提到一些关于SQL Server方面的一些问题&＃xff0c;褒贬不一&＃xff0c;他们也碰到了一些性能问题&＃xff0c;我给了一些个人的建议&＃xff0c;也不知道是否奏效。
Q&＃xff1a;SQL Server 2000的数据库压力很大&＃xff0c;CPU和内存老不够&＃xff0c;但是调整的时间又有限&＃xff0c;应该如何解决&＃xff1f;
从表面来看&＃xff0c;无疑是程序问题&＃xff0c;但是大多时候碰到这种情况是比较冤枉的
1&＃xff0e; 程序不是自己写的
2&＃xff0e; 在线系统已经没有足够的时间去调整程序
3&＃xff0e; 数据库设计有些致命的问题
4&＃xff0e; …..
不熟悉、不能和不足够时间&＃xff0c;我想问题大抵如此吧&＃xff0c;简单的建议如下
1&＃xff0e; 超过2G内存的机器&＃xff0c;请确定是否在启动参数中加入了 /PAE /3GB选项
2&＃xff0e; 是否在组策略中给运行SQL Server的帐号指派了使用AWE的权限&＃xff0c;假若没有&＃xff0c;查阅相关文档启用
3&＃xff0e; 在SQL Server中启用AWE&＃xff0c;需要通过sp_configure命令来做
4&＃xff0e; 将内存调整成固定内存&＃xff0c;2005会好一点&＃xff0c;如果是2000&＃xff0c;请务必检查启动日志&＃xff0c;设置太高的最小内存会有可能实效
5&＃xff0e; 这些都做了&＃xff0c;发现还是有问题&＃xff0c;升级到SQL Server 2005。
这些建议都是治标不治本的&＃xff0c;不过或许能够帮助适当缓解数据库的压力&＃xff0c;内存管理不当会让SQL Server晕菜的。
如果还是有问题&＃xff0c;如果还是不熟悉SQL Server&＃xff0c;不能修改程序&＃xff0c;更加没有足够的时间&＃xff0c;那么可以考虑做下面的一些工作
1&＃xff0e; 使用SQL Profiler&＃xff0c;抓出执行最长的这些语句&＃xff0c;然后看看那些where之后的字段是否建立了索引&＃xff0c;在该建立索引的地方建立索引
2&＃xff0e; 如果发现这个是比较复杂或者麻烦的事情&＃xff0c;使用SQL优化向导&＃xff0c;从某种意义上&＃xff0c;这个小工具还是可以帮助解决问题的&＃xff0c;听天由命吧&＃xff0c;能优化多少算多少
3&＃xff0e; 如果这个也没辙了&＃xff0c;看看那些执行效率比较低的代码是否是存储过程&＃xff0c;通过一些工具&＃xff0c;如SQL Expert&＃xff0c;来帮助你做一些SQL优化&＃xff0c;然后乖乖地拷贝回去
4&＃xff0e; 如果发现是插入语句过慢&＃xff0c;那么有可能是吃撑了&＃xff0c;也就是你的索引建多了&＃xff0c;适当看看语句的情况&＃xff0c;该去则去吧。
如果发现还是应用事件探查器优化SQL Server系统》&＃xff0c;利用read80trace来帮助你分析日志吧&＃xff0c;通过此能够找到一些通过你刚才方法无法找到的未建立索引&＃xff0c;苏先生已经讲述的非常详细&＃xff0c;我也不去COPY了。多废话几句&＃xff1a;不奏效&＃xff0c;那么推荐去阅读苏有全先生的《
1&＃xff0e; 关键集中在查询时间占据最多的语句&＃xff0c;基本上你可以理解为这是整体数据库系统消耗的百分比
2&＃xff0e; 另外可以适当看看I/O占有最大的语句&＃xff0c;可能适当的磁盘系统优化也能够帮你解决问题
因为这个问题回答的是希望能够最简单快速解决部分问题的情况&＃xff0c;一些比较复杂的情况和调整就不去做了&＃xff0c;虽然时日不长&＃xff0c;不过一时半会应该可以撑过去。
Q&＃xff1a;数据库中有某个表特别大&＃xff0c;导致查询性能比较低&＃xff0c;应该如何解决&＃xff1f;
这个问题是去参加TechED的时候路上和一个朋友讨论CSDN的Blog而引发的&＃xff0c;虽然我阅读过部分.Text的代码&＃xff0c;但是了解依旧有限&＃xff0c;只是从个人的角度给出了一些建议
1&＃xff0e; 如果这个表包括了大量的可空字段、频繁更新的字段&＃xff08;如点击数&＃xff09;、大文本&＃xff08;文章内容&＃xff09;&＃xff0c;再加上这个表超过10万条记录&＃xff0c;差不多剩下的日子就是等死了&＃xff0c;那么这个时候就是分拆。
a) 将文章和评论拆开&＃xff08;这点CSDN似乎很多年前就干了&＃xff09;
b) 将频繁更新的字段拆到另外一个表&＃xff0c;虽然我们可以说主表ID建立了聚集索引&＃xff0c;但是不管如何都存在读写锁的代价
c) 大文本字段务必拆解到另外一个表上&＃xff0c;因为不管如何&＃xff0c;你让一个表文件几十个G对系统没有任何好处
d) 另外不要将统计相关的信息和大文本放在同一个数据文件
e) 如果磁盘读些速率还有区别&＃xff0c;频繁更新的表所在的数据文件放在高速磁盘上
2&＃xff0e; 尽可能升级到2005&＃xff0c;从而利用其分区功能
3&＃xff0e; 根据业务调整分区规则&＃xff0c;一般来说&＃xff0c;按照年/月来归档就足够了&＃xff0c;详细的分区使用可以查阅相关的帮助
4&＃xff0e; 大多文本内容是可以缓存的&＃xff0c;如果非要使用MemCached&＃xff0c;尽量不要使用Windows版本的&＃xff0c;而是假设在Linux上
5&＃xff0e; 更加简单的做法是建立一个自己的CacheServer&＃xff0c;不需要太多的工作&＃xff0c;使用Remoting提供服务就可以了&＃xff0c;协议当然是TCP&＃xff0c;而后台可以利用HttpRuntime.Cache和文件来实现双缓冲&＃xff0c;如果担心文件读写在多线程的情况下会产生比较大的压力&＃xff0c;可以使用异步I/O来解决
6&＃xff0e; 维护一个自己的缓存过期列表&＃xff0c;尽量不工作&＃xff0c;而是通过时间戳判断来决定是否超时
7&＃xff0e; 缓存引发的另外一个问题是缓存超时或者对象更新&＃xff08;如文章更新&＃xff09;之后的对象移除&＃xff0c;可以利用MSMQ异步通知缓存系统删除缓存
8&＃xff0e; 当然了&＃xff0c;如果只有单台Web Server&＃xff0c;放在进程内是更加合理的
另外&＃xff0c;如果可以静态化的&＃xff0c;尽可能静态化&＃xff0c;因为静态HTML能够充分利用windows 2003的kernel mode cache
京公网安备 11010802041100号