MS SQL Server的一点学习记录

记录一点过程中的心得. 

1. 清空一张表用truncate替代delete, 效率会更高;

2. 四张表以上的联合查询要尽量避免出现, 在10w级别的四张表join操作上, 性能下降的已经非常明显; 大规模的联合查询除了在一些查询比较多的字段上建索引, 还应该考虑数据冗余以保障查询效率, 数据冗余的做法有很多种, 我比较喜欢用触发器的方式, 干净利落, 还有transection保障. 不过触发器在导入操作上并不按照insert来看待, 这点需要注意.触发器的insert和update表影响的都是inserted临时表, 如果需要, 可以从这个表中取得刚刚插入/更新的内容;

3. 做好一个查询, 把Execution plan打开,  跟一下看看, 哪个地方是性能瓶颈, 多考虑一下是否有改善的空间;

4. 数据库日志收缩可以节省很大的磁盘空间,  5分钟前, 我刚刚将一个测试数据库800+M的log文件收缩到1M;

5. 在存储过程中, 如果要将表名作为变量传递, 似乎必须采用拼接字符串的方式, 在存储过程结束的地方执行拼接好的字符串;

6. 简单的对于权限加以区分, 可以使用left join/join. 比如系统中对某一个数据集的搜索要求简单地用全部/部分区别, 那么这个时候可以对管理返回left join的结果, 而对普通用户返回join的结果;

7. 我现在很习惯用一张描述表来存放一些配置信息, 比如vulnerability的分类, 状态描述.  很多地方对这张表的依赖越来越强, 我也不知道这种方式是不是正确. 这个似乎是从Scott的.TEXT Blog数据库学习来的? 不过这个对于数据库的deploy造成了一个小麻烦 -- 我需要为这个表专门写一个.sql 脚本, MS SQL 2000好像没有提供对一张表生成.sql 脚本的功能, 这点不如MY SQL. MySql甚至可以把整个数据库dump到一个文本文件...[update:2007-06-12 我这里说的对一张表, 指的是对一张表里的数据=.= 以后作文写完要检查一遍...]

8. 对于查询操作, 我的看法是尽量从view中获取, 这样在日后数据表schema改变的时候,  对外查询的接口结构不变.  不过, 也有很多人不赞成使用 view,  认为如果数据库设计够合理的话完全没有必要在view上查询. 但是对于我这种喜欢建配置表的人来说, view似乎是必不可少的. 比如配置表里有两个字段-- intID, strDescription. 假如有strDescription 有两种: Astatus和Bstatus, 在某一个特殊的情况下, Astatus与Bstatus需要联合查询, 这个时候如果有一个Astatus的view 和一个Bstatus的view, 写法就会变得简单;

9. 对于更新操作, 当然是应当全部交给存储过程来完成,  写存储过程的时候需要注意,  不要是用sp简写作为自定义存储过程的命名, 因为在SQL Server中, 系统存储过程也是使用sp开头的, 在应用程序调用sp开头的存储过程时, 会先从系统存储过程找起, 所以改一个前缀可以略微提高存储过程的性能, 我用usp_作为前缀, 这个是刚进公司的时候受教的;

10. 数据库之间的传递可以采用Publisher-Subscriber 模型, 也可以用DTS包的方式, 对于Replciation, 我懂的不多, 只是知道怎么玩而已, 谨慎起见, 我还是会选择DTS包, 还需要继续学习...

以上如无特殊说明,数据库均是指MS SQL Server 2000.

上个月参加了一个关于SQL Server 2005的Training,  刚刚开始了解些皮毛,  就听说SQL Server  2008 又CTP了...
http://www.microsoft.com/sql/prodinfo/futureversion/default.mspx
http://weblogs.asp.net/pleloup/archive/2007/06/05/sql-2008-is-here-but-it-s-not-really-exciting.aspx

不是我不明白, 这世界变化快.