这里有一些非常有用的MSSQL注释。

简单恢复模型与完全恢复模型

简单模式

没有日志备份。
自动回收日志空间以减小空间需求，从根本上消除了管理事务日志空间的需要。

全模式

数据库上的完全恢复模式意味着我们打算能够在发生故障时恢复到某个时间点。
这意味着我们计划结合使用完整备份和事务日志备份(可能还有差异)。

SQL Server理解我们的意图，并且不会截断(释放文件中的空间。
注意文件保持不变，我没有说收缩，而是说截断。
截断会释放文件中的空间，收缩会删除" (使物理文件更小的空间)数据库的日志文件(.LDF文件)。
相反，它们将继续增长，直到您进行事务日志备份为止。

为什么要在创建备份之前缩小日志

正如Microsoft(和生活实践)所说，如果在Microsoft SQL Server 2008/R2或者Microsoft SQL Server 2012中还原数据库并构建虚拟日志文件(VLF)列表，则可能需要很长时间。
数据库。

SQL Server无法将日志记录从日志文件的末尾移到日志文件的开头。
这意味着，如果文件末尾为空，则SQL Server只能缩减文件大小。
最末端的日志记录设置了可以缩减事务日志的数量的限制。
事务日志文件以虚拟日志文件(VLF)为单位缩小。

获取所有数据库的T日志大小

要查看事务日志的大小以及正在使用的空间，请执行以下操作：

DBCC SQLPERF(logspace)

获取数据库的物理路径

USE master 
SELECT name, physical_name, size
FROM sys.master_files

获取数据库日志文件名和日志大小

USE database_name;
EXEC sp_helpfile

缩写日志

USE database_name;
ALTER DATABASE database_name SET RECOVERY SIMPLE;
DBCC SHRINKFILE (database_log_name, 1);
ALTER DATABASE database_name SET RECOVERY FULL;

重建表索引

重建过程将删除现有索引并重新创建索引。

USE database_name;
ALTER INDEX ALL ON dbo.table_name REBUILD

重组表索引

重新组织过程从物理上重新组织索引的叶节点。

USE database_name;
ALTER INDEX ALL ON dbo.table_name REORGANIZE

一般建议

当索引碎片大于40％时，应重建索引。
当索引碎片在10％到40％之间时，应该重新组织索引。

索引重建过程使用更多的CPU并锁定数据库资源，除非SQL Server支持ONLINE选项。
联机选项将在重建期间保持索引可用。

检查SQL Server指定的数据库索引碎片百分比

USE database_name;
SELECT OBJECT_NAME(ind.OBJECT_ID) AS TableName, 
ind.name AS IndexName, indexstats.index_type_desc AS IndexType, 
indexstats.avg_fragmentation_in_percent 
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, NULL) indexstats 
INNER JOIN sys.indexes ind 
ON ind.object_id = indexstats.object_id 
AND ind.index_id = indexstats.index_id 
WHERE indexstats.avg_fragmentation_in_percent > 30 
ORDER BY indexstats.avg_fragmentation_in_percent DESC

SQL查询来自：http://gallery.technet.microsoft.com/scriptcenter/Check-SQL-Server-a-a5758043