解惑

解己之惑,解人之惑

标签:SQL Server

不能导入mdf文件

今天帮一个朋友查问题,给了我MDF和LDF,死活不能导入,报错都是无法读取物理文件,根据它的出错信息给的链接到微软的网站结果是无更多的信息,google了下,有人说是用户问题,导出的时候是sql server2000,我用的是sql server 2005,所以attach的时候要用detach的用户,但是我的机器和他的机器完全不相干啊,后来想到也许是我登录的用户的问题,我安装的时候使用的是Mix模式,我登录studio的时候用的是sa用户,试着用windows authenticate,导入成功。
但是在这之前我手工的建了一个同名的数据库,然后detach掉了。
不知道到底是更换用户使得attach好使还是建同名数据库然后detach使得导入成功。

另外一个比较搞笑的事情就是打开mdf文件,开始提示是系统文件,可能会损坏,选择open with,提示是使用windows的服务自动查找还是从程序列表选择,选择windows查找,结果页面显示:

File Type: Unknown

Description: Windows does not recognize this file type.

最后就是2000下的MDF文件很小,变成2005就大了一倍多。

对Sql Server彻底失望

今天为QA写一个报表,使用了存储过程,在里面定义了一个临时表, 然后向临时表插入数据,插入数据的顺序和临时表的字段定义的顺序不一样,结果出来的结果乱七八糟,查了半天也没有想到什么原因,后来突然想到是不是和顺序有关,修改了insert语句里面的字段插入顺序,问题搞定。
唉,不知道是我对SQL了解太少还是SQL server确实很烂。

例子如下:
DECLARE @TEMP_TABLE TABLE (id int,count int)

insert INTO @TEMP_TABLE
select x.id as id, count(x.id) as count
from xxx x group by x.id

insert INTO @TEMP_TABLE
select count(x.id) as count), x.id as id
from xxx x group by x.id

上面的那个insert可以工作,下面的不能,得到的结果和期望的是不一致的

SQL Server性能问题

昨天遇到一个奇怪的性能问题,一个SQL对于某些用户特别的慢,需要2分钟以上,但是把那个SQL抓出来,把参数填进去直接运行又非常的快,只要不到2秒,猜测可能是和SQL Server的执行计划出了问题,以前遇到过类似的问题,在某些状况下,SQL Server的执行计划很糟糕,稍稍修改了下SQL,把参数中的一个常量值0直接写到SQL中,问题解决。
修改前的SQL片段(rfpId的值是0,1234两个值,修改后等于1234):
and x.yId in (:rfpId)
修改后:
and x.yId in (0,:rfpId)

原来遇到的一个性能问题类似,就是一个很复杂的SQL,对于某些用户也是非常的慢(该用户相关的数据比较多),查询可能需要2分钟,后来把复杂的SQL切分成两个SQL,总共的查询时间只需要不到1秒。

所以在使用SQL SERVER的时候,能够直接在SQL里面固定的值直接写到SQL里面,不要写太复杂的SQL,SQL Server的执行计划优化器存在很多的问题。

© 2024 解惑

本主题由Anders Noren提供向上 ↑