经常光顾ｓｑｌｓｅｒｖｅｒ板块，看到很多人问关于收缩数据库的问题。个人觉得没有必要收缩。　

引用楼主 andkylee 的回复:

本人是sybase-dba，也顺便兼职搞搞sqlserver。基于sybase的经验，我觉得没有必要经常收缩sql server数据库的大小或者数据文件文件的大小。

因为在sybase中迄今没有能够减小已经分配数据库大小的办法，也就是说：在sybase中数据库的空间大小只能涨不能降。其实，这不是sqlserver没必要收缩的原因。

在sql server中数据文件中会随着时间而产生一些……

SQL SERVER 收缩数据库其实是这样

如果你是开发数据库，你可以选择SIMPLE方式， 生产数据库也不要经常去收缩数据库，这并不是一个好的习惯。

另外LZ 能介绍一下SYBASE 数据库的一些情况吗，目前使用的人的确不多，或者能分享一点数据库维护的经验

谢谢

收缩自然有它存在的意义，比如说磁盘空间不够等。

收缩可减少磁盘空间

收缩是可以减小数据库文件大小的 将不用的空间还给操作系统的。
SHRINKFILE SHRINKDATABASE 这2个操作都是能指定TRUNCATEONLY 选项：
将文件末尾的所有可用空间释放给操作系统，但不在文件内部执行任何页移动。数据文件只收缩到最后分配的区。
TRUNCATEONLY 只适用于数据文件。

至于日志 进过日志备份后进行收缩也是可以改变大小的~

引用 2 楼 liuhuayang 的回复:

引用楼主 andkylee 的回复:
本人是sybase-dba，也顺便兼职搞搞sqlserver。基于sybase的经验，我觉得没有必要经常收缩sql server数据库的大小或者数据文件文件的大小。

因为在sybase中迄今没有能够减小已经分配数据库大小的办法，也就是说：在sybase中数据库的空间大小只能涨不能降。其实，这不是sqlserver没必要收缩的原因。

在sql s……

我的csdn博客里面就有一些我分享的sybase经验~

引用 3 楼 sqlcenter 的回复:

收缩自然有它存在的意义，比如说磁盘空间不够等。

开发环境中可能会有磁盘不足的情况。 
真正在生产环境中，不会或者不应该出现磁盘不足的情况。 因为需要全备和增量备份，还有多份。数据库恢复模式设置成完全模式。

在收缩数据库的时候势必会对已有的备份策略产生影响，所以在生成环境中很少有人进行收缩数据库的操作。 

若要收缩特定数据库的所有数据和日志文件，请执行 DBCC SHRINKDATABASE 命令。若要一次收缩一个特定数据库中的一个数据或日志文件，请执行 DBCC SHRINKFILE 命令。

若要查看数据库中当前的可用（未分配）空间量，请运行 sp_spaceused。

可在进程中的任一点停止 DBCC SHRINKDATABASE 操作，任何已完成的工作都将保留。

收缩后的数据库不能小于数据库的最小大小。最小大小是在数据库最初创建时指定的大小，或是使用文件大小更改操作（如 DBCC SHIRNKFILE 或 ALTER DATABASE）显式设置的最后大小。例如，如果数据库最初创建时的大小为 10 MB，后来增长到 100 MB，则该数据库最小只能收缩到 10 MB，即使已经删除数据库的所有数据也是如此。

运行 DBCC SHRINKDATABASE 而不指定 NOTRUNCATE 选项或 TRUNCATEONLY 选项等价于带 NOTRUNCATE 运行 DBCC SHRINKDATABASE 操作，然后再带 TRUNCATEONLY 运行 DBCC SHRINKDATABASE 操作。

要收缩的数据库不必在单用户模式下；其他的用户仍可以在数据库收缩时对其进行工作。这也包括系统数据库。

不能在备份数据库时收缩数据库。反之，也不能在数据库执行收缩操作时备份数据库。
DBCC SHRINKDATABASE 的工作原理

DBCC SHRINKDATABASE 以每个文件为单位对数据文件进行收缩。然而，DBCC SHRINKDATABASE 在对日志文件进行收缩时，它将视为所有的日志文件都存在于一个连续的日志池中。文件始终从末尾开始收缩。

假设名为 mydb 的数据库有一个数据文件和两个日志文件。数据文件和日志文件分别是 10 MB，并且数据文件包含 6 MB 数据。

对于每个文件，数据库引擎都会计算一个目标大小。这就是文件将要收缩到的大小。将 target_percent 与 DBCC SHRINKDATABASE 一起指定时，数据库引擎计算的目标大��是收缩后文件中的 target_percent 可用空间大小。例如，如果在收缩 mydb 时将 target_percent 指定为 25，则数据库引擎将此文件的目标大小计算为 8 MB（6 MB 数据加上 2 MB 可用空间）。因此，数据库引擎将任何数据从数据文件的后 2 MB 中移动到数据文件前 8 MB 的可用空间中，然后对该文件进行收缩。

假设 mydb 的数据文件包含 7 MB 的数据。将 target_percent 指定为 30，以允许将此数据文件收缩到可用空间的 30％。但是，将 target_percent 指定为 40 却不会收缩数据文件，因为数据库引擎收缩文件的目标大小不能小于数据当前占用空间大小。您还可以用另一种方法来考虑此问题：所要求的 40％ 可用空间加上整个数据文件大小的 70％（10 MB 中的 7 MB），超过了 100％。因为所要求的可用百分比加上数据文件占用的当前百分比大于 100%（多出 10%），所以任何大于 30 的 target_size 都不会收缩此数据文件。

对于日志文件，数据库引擎使用 target_percent 来计算整个日志的目标大小；因此，target_percent 是收缩操作后日志中的可用空间大小。之后，整个日志的目标大小转换为每个日志文件的目标大小。

DBCC SHRINKDATABASE 尝试立即将每个物理日志文件收缩到其目标大小。如果虚拟日志中的所有逻辑日志部分都没有超出日志文件的目标大小，则该文件将成功截断，DBCC SHRINKDATABASE 完成且不显示任何消息。但是，如果部分逻辑日志位于超出目标大小的虚拟日志中，则数据库引擎将释放尽可能多的空间，并发出一条信息性消息。该消息说明需要执行哪些操作来将逻辑日志移出位于文件末尾的虚拟日志。执行该操作以后，DBCC SHRINKDATABASE 可用于释放剩余空间。有关详细信息，请参阅收缩事务日志。

因为日志文件只能收缩到虚拟日志文件边界，所以不可能将日志文件收缩到比虚拟日志文件更小（即使现在没有使用该文件）。虚拟日志文件的大小在创建或扩展这些日志文件时由数据库引擎动态选择。有关虚拟日志文件的详细信息，请参阅事务日志物理体系结构。
最佳做法

当您计划收缩数据库时，请考虑以下信息：

    * 在执行会产生许多未使用空间的操作（如截断表或删除表操作）后，执行收缩操作最有效。
    * 大多数数据库都需要一些可用空间，以供常规日常操作使用。如果反复收缩数据库并注意到数据库大小变大，则表明收缩的空间是常规操作所必需的。在这种情况下，反复收缩数据库是一种无谓的操作。
    * 收缩操作不会保留数据库中索引的碎片状态，通常还会在一定程度上增加碎片。这是不要反复收缩数据库的另一个原因。
    * 除非有特定要求，否则不要将 AUTO_SHRINK 数据库选项设置为 ON。

貌似没有很大的意义

迄今为止还没看出收缩有什么效果

最直观的效果就是可以节省磁盘空间啊 
如果设置不好的时候，日志文件空间会暴增，备份后还原速度不是一般的慢
所以收缩数据库有时还是必须的

引用 12 楼 crszf 的回复:

最直观的效果就是可以节省磁盘空间啊 
如果设置不好的时候，日志文件空间会暴增，备份后还原速度不是一般的慢
所以收缩数据库有时还是必须的

能解释一下还原的时候为什么慢吗？  
个人觉得理论上不应该慢！

引用 12 楼 crszf 的回复:

最直观的效果就是可以节省磁盘空间啊 
如果设置不好的时候，日志文件空间会暴增，备份后还原速度不是一般的慢
所以收缩数据库有时还是必须的

怕日志暴涨， 可以备份日志或者截断日志。 

我觉得有用
但我理解的很混乱
数据库很大的时候，做查询、插入会慢，减小他的自动增加比例值就稍微好些
同理…………

當數據量大時你就覺得有必要了......

收缩减小占用磁盘空间的大小，但如果你想提高性能的，仅收缩一下数据库是没有太大的用处的，要想提
高性能的化，应该从多方面的考虑。服务器配置、内存、服务器I/O操作，查询语句优化以及大的表应
采取分区表的形式等。

磁盘空间…

引用 15 楼 ccs02287 的回复:

我觉得有用
但我理解的很混乱
数据库很大的时候，做查询、插入会慢，减小他的自动增加比例值就稍微好些
同理…………

查询插入的快慢和数据库大小有关系。　和里面的碎片倒是有关系，但是收缩能清理碎片吗？

收缩远没有您想的那样简单，有很多因素和前提的影响。

在没有前提的情况下，回答可能都是事实而非的。这其中涉及到区还有统计信息等

只有在需要磁盘空间或者异常增大时才对数据库进行收缩。。

总之，收缩是一个不怎么推荐的操作。。

引用 20 楼 claro 的回复:

收缩远没有您想的那样简单，有很多因素和前提的影响。

在没有前提的情况下，回答可能都是事实而非的。这其中涉及到区还有统计信息等

你要是了解的话，请从“这其中涉及到区还有统计信息等”角度帮忙分析一下。 

习惯后差不多

收缩可减少磁盘空间

引用 17 楼 lzd_83 的回复:

收缩减小占用磁盘空间的大小，但如果你想提高性能的，仅收缩一下数据库是没有太大的用处的，要想提
高性能的化，应该从多方面的考虑。服务器配置、内存、服务器I/O操作，查询语句优化以及大的表应
采取分区表的形式等。

是这样的 

受益很浅

best practice是永远不要收缩文件或日志。如果你需要shrink，说明你dba工作没做好。

收缩 数据库 是非常耗费server性能的操作，如果没有必要不要收缩
go 
收缩 无非就是把已经分配给数据库文件空间收回来，但是，收缩的时候 要移动数据页，而且可能造成大量的碎片，影响性能。
go 
日志收缩和数据文件收缩不一样，日志中的虚拟文件状态 只有 在可复用 时候  才能收缩。
而且 凡是有活动的日志的日志虚拟文件都是活动的不能收缩。
go

我一般是不会收缩的，除非有特别大的项目数据更新，导致mdf或ldf文件已经大到压根就不会需要的大小的地步。

日志文件收缩， 回收磁盘空间。
数据文件 根据设计  设计的大小，一般情况不用收缩，收缩可能带来性能的问题。
日志
如果 选择的日志恢复模型是完全，如果没有日志截断，日志增长的很大，
建议
备份日志。
backup log db to disk='备份设备'
截断日志
backup log db with no_log
然后收缩。
dbcc shrinkfile(2,10)