在SQL Server数据库中，数据文件与事务日志文件的修改日期（Date Modified）是会变化的，但是有时候你会发现你的数据文件或日志文件的修改日期（Date Modified）几个月甚至是半年以上都没有变化了，如下截图所示：
为什么呢？不会是什么bug吧？ 相信很多人都会有这样的反应。下面我们通过实验来看看数据库的数据文件与事务日志文件在什么情况或条件下， 修改日期（Date Modified）才会变化.首先创建一个TEST数据库，查看其数据文件或事务日志文件的修改日期如下：
USE [master];
GO
CREATE DATABASE [TEST] ON PRIMARY
(
NAME = N'TEST',
FILENAME = N'E:\SQL_DATA\test.mdf' ,
SIZE = 32MB ,
MAXSIZE = UNLIMITED, FILEGROWTH = 1MB
) LOG ON
(
NAME = N'TEST_LOG',
FILENAME = N'E:\SQL_DATA\test_log.ldf' ,
SIZE = 4MB ,
MAXSIZE = 2048GB ,
FILEGROWTH = 10%
);
GO
我们先查看一下数据库数据文件大小、空间使用情况，依此以为参照，判别数据库数据文件或事务日志的增长情况
USE TEST;
GO
SELECT DB_NAME(database_id) AS DataBaseName
,Name AS LogicalName
,type_desc AS FileTypeDesc
,Physical_Name AS PhysicalName
,CAST(size * 8.0 / 1024 AS DECIMAL(8, 4)) AS [Size(MB)]
,FILEPROPERTY(name, 'SpaceUsed') * 8.0/1024 AS [Used_Size(MB)]
,CURRENT_TIMESTAMP AS CURRENT_DATETIME
FROM sys.master_files
WHERE database_id = DB_ID('TEST');
我们通过一个大批量插入操作，使数据库的数据文件实现自增长，如下所示，当数据库的数据文件或事务日志文件增长时，其修改日期就会变化。
SET NOCOUNT ON;
GO
CREATE TABLE TEST (OBJECT_ID INT, NAME VARCHAR(600));
CREATE CLUSTERED INDEX PK_TEST ON TEST(OBJECT_ID)
DECLARE @Index INT =0;
WHILE @Index < 200000
BEGIN
INSERT INTO TEST
SELECT @Index, REPLICATE('it is only test', 40); SET @Index = @Index +1;
END
GO
然后你用执行一些其他DML操作，前提是不要使数据文件增长，那么你会发现数据库数据文件与事务日志文件的修改日期是不会变化的，也就是说即使数据库的数据文件和日志文件有读写操作，它的修改日期是不会变化的，这个跟普通文件是有区别的。
DECLARE @Index INT =0;
WHILE @Index < 20
BEGIN
INSERT INTO TEST
SELECT @Index, REPLICATE('it is only test', 40); SET @Index = @Index +1;
END
GO
所以即使你看到你的数据库里面数据文件或事务日志文件的修改日期是几天前、甚至是几个月前的日期，也不要大惊小怪，这个并不代表这这个数据库并没有任务事务操作或活动事务，而是仅仅因为数据库的数据文件和事务日志文件没有扩展而已。因为可能数据文件或事务日志文件有大量空间可用，或是最近数据增长很少的缘故。
那么还有那些操作会修改数据库的数据文件与事务日志文件的修改时间（Date Modified）呢？ 总结归纳起来有下面一些操作：
1：数据文件或事务日志文件的自增长或调整大小（使用SQL语句调整数据文件大小也会改变修改时间）
2：数据文件或事务日志文件的收缩会修改数据文件的修改日期。
3：分离附加数据库或脱机联机操作会修改数据文件的修改日期。
4：重启数据库服务也会修改数据文件的修改日期（有些数据库的数据库文件的修改日期会变化，有些也不会变化）
当然，应该还有一些其他操作也有可能导致数据库数据文件或事务日志文件的修改日期变化，没法一一实验测试验证，在此略过。
PS：本文是同事想以数据文件的修改日期来判断数据库最近的活动时间，结果发现这么一个现象，所以做了一下这方面的研究和总结。