数据库空间不足怎么解决？

一、用户数据库搬家

*** 作方法有以下两种

方法1：在企业管理器中进行

（1）在企业管理器中选定要搬家的数据库名，在其上单击鼠标右键，出现如图1所示对话框。

（2）选中“所有任务”，在其子菜单中单击“分离数据库”。

（3）将该数据库的数据文件和日志文件从旧的位置（如D:\MSSQL\Data）拷贝到新的位置（如E:\SQLDataNew）。

（4）再在企业管理器中选中“数据库”文件夹，在其上单击鼠标右键，在出现的对话框中选中“所有任务”，在其子菜单中单击“附加数据库”。

（5）在出现的“附加数据库”对话框中，选择数据库的两个文件的新位置。

方法2：用SQL系统存储过程sp_detach_db/sp_attach_db实现

（1）使用下面语句分离数据库：

USE master

GO

EXEC sp_detach_db 'mydb'

GO

（2）将该数据库的数据文件和日志文件从旧的位置拷贝到新的位置。

（3）使用下面语句重新附加数据库：

USE master

GO

EXEC sp_attach_db

'mydb', 'E:\SQLDataNew\mydbdata.mdf', 'E:\SQLDataNew\mydblog.ldf''

GO

二、系统数据库搬家

1．master数据库搬家

（1）由于SQL Server每次启动的时候都需要读取master数据库，因此必须在企业管理器中改变SQL Server启动参数中master数据文件和日志文件的路径。

在 SQL Server属性的“常规”选项卡下面有一个叫做“启动参数”的按钮，单击后可以看到所示的界面。

其中，-d用来指定master数据库文件的路径，而–l用来指定master数据库日志文件的路径。

删除旧的master数据库文件和日志文件的路径，添加新的master数据文件和日志文件所在的路径，如：

-dE:\ SQLDataNew \master.mdf

-lE:\ SQLDataNew \mastlog.ldf

（2）停止SQL Server服务，将master.mdf文件和mastlog.ldf文件拷贝到新的位置，如E:\ SQLDataNew文件夹中。

（3）重新启动服务即可。

小技巧：如果在“启动参数”添加的master数据库文件和日志文件的路径或文件名有误，就会造成SQL Server启动不起来。而此时想改正错误又因SQL Server启动不了而重设不了“启动参数”。其实这两个文件路径和文件名是放置在注册表HKEY_LOCAL_MACHINE\SOFWARE\Microsoft\Miccrosoft SQL Server\你安装SQL服务器的名\MSSQLServer\Parrmeters下的参数SQLArg1和SQLArg2中，修改这两个参数的值即可。

2. msdb数据库和model数据库搬家

（1）对于msdb数据库和model数据库，我们不能在企业管理器中实现分离和附加，只能用sp_detach_db和sp_attach_db存储过程来分离和附加这两个数据库。

其中，对于msdb数据库，还应确保SQL Server代理当前没有运行，否则sp_detach_db存储过程将运行失败，并返回如下消息：

“无法除去数据库 'msdb' ，因为它当前正在使用。”

（2）调出如图4所示的“启动参数”对话框，添加新参数-T3608。这样，启动SQL Server，它就不会恢复除master之外的任何数据库。

（3）重新启动SQL Server，再用下面命令分离msdb或者model数据库：

EXEC sp_detach_db 'msdb'

GO

（4）将数据文件和日志文件移到新的位置，然后再用下面命令重新附加msdb数据库或者model数据库：

USE master

GO

EXEC sp_attach_db

'msdb', ‘E:\SQLDataNew\msdbdata.mdf', ' E:\SQLDataNew\msdblog.ldf '

GO

（5）在企业管理器中，从“启动参数”框中删除-T3608跟踪标记，再停止并重新启动SQL Server。

3. tempdb数据库搬家

对于tempdb数据库，则可以直接使用ALTER DATABASE语句来为数据文件和日志文件指定新的存放位置，如下所示：

USE master

GO

ALTER DATABASE tempdb MODIF

Y FILE (NAME=tempdev, FILENAME ='E:\SQLDataNew \tempdb.mdf')

GO

ALTER DATABASE tempdb MODIF

Y FILE(NAME=templog, FILENAME=

' E:\SQLDataNew \templog.ldf')

GO

至此，SQL Server 中数据库全部搬家完成。

varchar是可变字符，varchar(2000)即可，不会浪费空间。

楼主为何要将历史记录存在access中呢？若您后台有sql server支持，建议您历史记录也存放在sql中，access的性能及对sql的语言支持都远不如 MSSQL。

【VARCHAR限制了字符串的长度不能超过255个字符?】---哦，忘记了，这个可能access有此限制，sql可以的，最大varchar（8000）。

varchar(100)中的100并不多余，在未存储数据时用于占位，系统会用于预先计划分配空间，但直到真正存储数据时才确实分配存储空间。

个人看法：

1.占用空间上varchar（100）和varchar（2000）没什么区别。

2.但varchar(100)会效率较低，因为按你说的该字段会5-2000，若大于100，则您每次固定写入100会需要多次写 *** 作，众所周知写 *** 作是比较耗时的。

3.查询性能方面，跟您这儿怎么存没太大关系，重要的还是常见的数据库查询优化，如索引、条件等等

对这个问题，我引用一下CSDN上的说法：

一。数据行结构

char(n): 系统分配n个字节给此字段，不管字段实际长度(后边用空格补齐)

varchar(n): 假设表中有M个varchar(或者nvarchar)类型的字段

先分配两个字节(用来表示M)

再分配2*M个字节(表示各变长行的偏移)

此后字段值有多长，就分配多长

二。varchar(n)一定比char(n)节省空间么?

不一定。

我见过这样的设计: varchar(3)

就算此字段为空，也还是比char(3)多用一个字节。

还有这样的设计: user_ip varchar(16).

对于这种数据长度变化不大的字段，用varchar只能浪费空间

结论: varchar适用于数据值长度不太短，且长度变化较大的字段

三。char(n)一定比varchar(n)速度快么?

不一定

计算varchar的偏移是会花去一些cpu时间，但性能瓶颈不在此，在io.

db的io单位是数据页(8192字节)(一页存有多个数据行，数据行不能跨页。当然image,text等例外). 因此一页中行越多，性能越好

另外，关于char和varchar的性能比较，

请参见该实验：

http://www.yuanma.org/data/2006/0730/article_1266.htm

再补充一下：

[转帖]char、nchar、varchar、nvarchar，对比那个好？

数据库定义到char类型的字段时，不知道大家是否会犹豫一下，到底选char、nchar、varchar、nvarchar、

text、ntext中哪一种呢？结果很可能是两种，一种是节俭人士的选择：最好是用定长的，感觉比变长能省些空

间，而且处理起来会快些，无法定长只好选用定长，并且将长度设置尽可能地小；另一种是则是觉得无所谓，

尽量用可变类型的，长度尽量放大些。

鉴于现在硬件像萝卜一样便宜的大好形势，纠缠这样的小问题实在是没多大意义，不过如果不弄清它，

总觉得对不起劳累过度的CPU和硬盘。

下面开始了(以下说明只针对SqlServer有效)：

1、当使用非unicode时慎用以下这种查询：

select f from t where f = N'xx'

原因：无法利用到索引，因为数据库会将f先转换到unicode再和N'xx'比较

2、char 和相同长度的varchar处理速度差不多（后面还有说明）

3、varchar的长度不会影响处理速度！！！（看后面解释）

4、索引中列总长度最多支持总为900字节，所以长度大于900的varchar、char和大于450的nvarchar,nchar

将无法创建索引

5、text、ntext上是无法创建索引的

6、O/R Mapping中对应实体的属性类型一般是以string居多，用char[]的非常少，所以如果按mapping的

合理性来说，可变长度的类型更加吻合

7、一般基础资料表中的name在实际查询中基本上全部是使用like '%xx%'这种方式，而这种方式是无法利用

索引的，所以如果对于此种字段，索引建了也白建

8、其它一些像remark的字段则是根本不需要查询的，所以不需要索引

9、varchar的存放和string是一样原理的，即length {block}这种方式，所以varchar的长度和它实际占用

空间是无关的

10、对于固定长度的字段，是需要额外空间来存放NULL标识的，所以如果一个char字段中出现非常多的NULL，

那么很不幸，你的占用空间比没有NULL的大（但这个大并不是大太多，因为NULL标识是用bit存放的，

可是如果你一行中只有你一个NULL需要标识，那么你就白白浪费1byte空间了，罪过罪过！），这时候，

你可以使用特殊标识来存放，如：'NV'

11、同上，所以对于这种NULL查询，索引是无法生效的，假如你使用了NULL标识替代的话，那么恭喜你，

你可以利用到索引了

12、char和varchar的比较成本是一样的，现在关键就看它们的索引查找的成本了，因为查找策略都一样，

因此应该比较谁占用空间小。在存放相同数量的字符情况下，如果数量小，那么char占用长度是小于varchar

的，但如果数量稍大，则varchar完全可能小于char，而且要看实际填充数值的充实度，比如说varchar(3)

和char(3)，那么理论上应该是char快了，但如果是char(10)和varchar(10)，充实度只有30%的情况下，

理论上就应该是varchar快了。因为varchar需要额外空间存放块长度，所以只要length(1-fillfactor)

大于这个存放空间（好像是2字节)，那么它就会比相同长度的char快了。

13、nvarchar比varchar要慢上一些，而且对于非unicode字符它会占用双倍的空间，那么这么一种类型

推出来是为什么呢？对，就是为了国际化，对于unicode类型的数据，排序规则对它们是不起作用的，

而非unicode字符在处理不同语言的数据时，必须指定排序规则才能正常工作，所以n类型就这么一点好处。

总结陈词：

1、如果数据量非常大，又能100%确定长度且保存只是ansi字符，那么char

2、能确定长度又不一定是ansi字符或者，那么用nchar；

3、不确定长度，要查询且希望利用索引的话，用nvarchar类型吧，将它们设到400；

4、不查询的话没什么好说的，用nvarchar(4000)

5、性格豪爽的可以只用3和4，偶尔用用1，毕竟这是一种额外说明，等于告诉别人说，我一定需要长度

为X位的数据

---