数据库在运行的时候突然增加进程数量是什么原因

不同的数据库的处理是不同的，有的数据库是你执行完程序，索引就更新完成了，有的数据库是自己评测系统资源空闲的时候做自身的更新（比如你在往有索引的表中增加了大量的数据，数据很快被加载进去了，但是索引可能是没有被维护的，这个数据库就会在系统资源空余的时间来维护索引的）。

但是可以确定的是你为一个字段创建索引的时间就是你执行程序的时间（是你单独创建的索引，并不是数据库通用维护的索引）

你可以测试一下的，你创建完索引后看看查库的速度是否有提升，就是最好的验证了。

SQL Server的内存一直上不去。从Task Schedule中看到SQL Server只使用了88MB内存，实际这台机器有12GB的内存，可用内存有超过8GB。 当时我以为是开启了AWE导致的，所以连接到他的服务器看了一下。但是数据库为2005企业版64位，所以不用开启AWE。而且即使开启了，也会被忽略。 使用下面的脚本查询了一下SQL Server内存使用： select physical_memory_in_use_kb,locked_page_allocations_kb,*fromsys.dm_os_process_memory 看到实际使用的内存有2GB，远远超出任务管理器看到的。(也可以通过Perfmon的Total server memory(MB)查看)。 当时觉得很奇怪，查看了SQL Server错误日志发现了类似下面的信息： 2009-06-0412:21:08.16 Server Large Page Extensions enabled. 2009-06-04 12:21:08.16 Server Large Page Granularity: 2097152 2009-06-04 12:21:08.21 Server Large Page Allocated: 32MB 猜测这台期间开启了Lock Pages In memory功能，之后得到确认。因为开启Lock Pages In memory之后，SQL Server会使用AWE APIs锁定内存页，所以这部分的内存使用不会显示在Working Set中。 So in summary the AWE APIs for 32bit and 64bit SQL Server systems are used for different purposes. In 32bit it is really to extend memory access beyond 4Gb or to enable the AWE feature. For 64bit systems, it is to possibly gain performance and to “lock pages” for the buffer pool. 到现在这个问题就比较明朗了，其实SQL Server还是正常工作的。一般查询SQL Server的使用还是建议使用DMV或者Perfmon，直接查看Working Set信息可能不准。 另外说一下，当时看到上面Large Page的信息，以为是数据库开启了LargePage，但是使用DBCC TRACSTATUS查看没有开启834 Trace Flag,所以大数据功能是没有启用的。只有开启834 Trace Flag数据库才会真正启用Large Page。 启用Large page在数据库错误日志会看到类似信息： 2009-06-0414:20:40.03 Server Using large pages for buffer pool. 关于Lock Pages In memory/working set机制我找到了两篇文章，大家有兴趣可以参考： Funwith Locked Pages, AWE, Task Manager, and the Working Set WhySQL Server is using so LESS memory

---