我看ms sql server 2000 (1) - 开头

PromisingChina

看了LZ的空间，更加佩服。
如有冒犯之处，多多包涵。

gargoyle

学习。

lfree

>对15楼问题：
>以前没玩过Oracle，还真不知道这些分别。
>但是，对于Oracel事务的设计，我有点难以接受。事务按定义不就是要保证我若干运算能同进同退吗？如果是我改别人也能改，理论上是不能滚回的。
>这里，如果Oracle默认是能读，我可以接受，如果默认使能写，有点问题，绝对逻辑问题。
>同时，按照LZ的观察：MS SQL已经能做到Row Level Lock，因为
>    select * from customers where customerid='ALFKJ'; 有问题
>    select * from customers where customerid='ALFKI'; 没问题

关于这个问题,oracle的查询仅仅的结果仅仅针对的当时时刻的结果,假设你做一个记数查询,需要5分钟得出结果,并且前台还对这个表进行大量DML:

select count(*) from bigtable

在oracle下这个结果是确定的,就是你发select的时刻的结果,如果执行不下去,多半是回滚段太小.

而ms sql就不同结果,是不确定的.
要得到正确结果,必须lock 表,再进行计算.

所以我一直认为oracle的一致性读取是一个很优秀的设计,特别在大并发用户的情况下.

lfree

set statistics io on
set implicit_transactions on
select btbt from orders(index(btbt)) where CONVERT(nvarchar(100),shipname+shipaddress+shipcity+shipregion+'1234567890123456789012345678901234567890' ) ='laji'
select btbt from orders where CONVERT(nvarchar(100),shipname+shipaddress+shipcity+shipregion+'1234567890123456789012345678901234567890' ) ='laji'
select * from orders(index(btbt)) where btbt ='laji'

IO统计如下:
表 'Orders'。扫描计数 1，逻辑读 1670 次，物理读 0 次，预读 0 次。
表 'Orders'。扫描计数 1，逻辑读 21 次，物理读 0 次，预读 0 次。

执行计划如图(S12):

可以发现直接使用表达式是无法直接使用btbt索引的.

[ 本帖最后由 lfree 于 2009-6-15 09:29 编辑 ]

lfree

在优化ms sql server 2000时,我曾经在itpub上问过,ms sql server是否要考虑绑定变量的问题,我在一些优化的书籍上也提到这方面的问题,使用它应该有一些好处.但是对实际性能的影响确实很小的(我个人认为的).但是对于oracle,特别在8i下,不使用绑定变量,对系统影响还是蛮大.

    但是如果原来在使用ms sql server数据库的程序员,在将程序迁移到oracle时往往忽略这些问题.实际我一直认为,如果现在再开发新程序在oracle下还没有合理的使用绑定变量,这样的团队应该淘汰掉!

[ 本帖最后由 lfree 于 2009-6-15 09:29 编辑 ]

bcsvr2

sql server 支持多种锁定方式，也可以设置不锁表的
对于这个一致性比较，有人专门分析过。
oracle是得到当时select时的数据
sql server 锁表的原因是得到更准确的数据
当然也可以设置成不锁表模式

对于我们HIS应用来说，其实是无所谓。
因为已经发生的费用数据，基本不允许直接修改的。

lfree

曾经听一位朋友提到过,他们的一个项目(ms sql server下)最后做不下去,就是在数据库下使用视图太多了.在http://www.sql-server-performance.com/网站上,提到视图对性能的影响,具体链接找不到了.

我个人遇到过这些问题,我发现在视图在与别的表连接的sql中,逻辑读都很高!如果我把这些sql重写,把视图去掉,发现执行计划变化很大,逻辑读并不是大!我个人的看法就是ms sql server在处理视图相关的执行计划中存在性能问题!

另外我看书的时候,发现ms下视图(不是oracle的物化视图)也能够建立索引.

有关连接看:
http://www.yafla.com/papers/SQL_ ... ql_server_pt2_1.htm

我自己有点不理解,在基表上建立索引就可以了.或许是2次查询的时候能够加快一些.

如图:

lfree

create table t( id int , a char(100),b varchar(100));
insert into t values(1,'a','b')
commit

set statistics io on
set implicit_transactions on
select a+'x',b+'x' from t

如图(S14)

可以看出使用char,是固定长度,消耗固定的空间,我们以前一套系统(oracle),使用了大量的char类型,结果导致空间的浪费!
(具体可以看看MS sql server 联机丛书的帮助:char 和 varchar )

lfree

set statistics io on
set implicit_transactions on
Declare @va  char(100), @vb  Varchar(100),
        @vxa  Varchar(100),@vxb  char(100)
Select @va = 'a' , @vb='b'
Select @vxa = 'a' , @vxb='b'
select * from t where a=@va
select * from t where b=@vb
select * from t where a=@vxa
select * from t where b=@vxb

执行计划如图(S15):

可以发现这两者变量是相容的,不存在转换问题,视乎有一个参数控制这种是否相容(我记不得了).也有结果返回!

IO统计:
（所影响的行数为 1 行）
表 't'。扫描计数 1，逻辑读 1 次，物理读 0 次，预读 0 次。
（所影响的行数为 1 行）
表 't'。扫描计数 1，逻辑读 1 次，物理读 0 次，预读 0 次。
（所影响的行数为 1 行）
表 't'。扫描计数 1，逻辑读 1 次，物理读 0 次，预读 0 次。
（所影响的行数为 1 行）
表 't'。扫描计数 1，逻辑读 1 次，物理读 0 次，预读 0 次。

lfree

我看ms sql server 2000 (16) - char 与 nvarchar 之3

接着上面的测试:
set statistics io on
set implicit_transactions on
Declare @va  char(100), @vb  Varchar(100),
        @vxa  Varchar(100),@vxb  char(100)
Select @va = 'a' , @vb='b'
Select @vxa = 'a' , @vxb='b'

select * from t where @va=@vxa
select * from t where @vxa=@va
select * from t where @vb=@vxb  
select * from t where @vxb=@vb  

结果是相同的.

但是oracle,如果你定义char类型的字段,如果你变量定义是varchar的(各种开发工具的可能有点不同),在char类型后面有空格的情况下:
这个是没有结果返回的,这样导致的结果是将程序移植到oracle是,程序员破天荒的使用oracle的triim函数.
参考链接:
http://www.itpub.net/thread-961107-1-1.html