我在使用同一个应用程序对同一个数据库的两个副本时的 .Net 应用程序内存使用情况存在很大差异。唯一的区别是，在场景 1 中，我使用注册到实例的数据库的本地副本SQL Server 2005 Express- 而在场景 2 中，我使用注册到实例的数据库的远程副本SQL Server 2008 Enterprise。
据我所知，我只希望 SQL 性能和 SQL 内存使用有所不同（因为 Express 有 1GB 的限制）。
但是 - 我看到的是它们之间内存使用量的巨大差异（1GB） - 即SQL Express主要使用 1GB 内存的场景。 SQL Express似乎也慢得多，特别是在处理大表和大查询时——但我希望这个内存命中出现在 SQL 中，而不是在我的消费/客户端应用程序上？？？
System.Data.SqlClient.SqlConnection该应用程序使用和执行频繁SqlCommand的操作连接到 SQL 服务器SqlBulkCopy。
任何有用的想法将不胜感激！
For you second question about slow express on big tables and queries, that is normal because express version is consuming more memory and disk than enterprise version. The Enterprise version is using a feature called Enhanched-Read-ahead and Scan(a.k.a Merry-go-round scans),which has enormous difference in performance of large queries.
For example:
Assume that UserA and UserB both issue the SELECT * FROM Customer command, which results in a table scan. UserA issues the command first; UserB issues the command 20 seconds later. The table has 100 million rows (it's a very big table), and the scan is running on a machine that has non Enterprise Edition installed. The table scan for UserA begins reading the Customer table on the first page of the table. Twenty seconds later, the scan for UserB starts reading pages that UserA has already read, even though some of the pages might already have been flushed back out of cache. Sometimes this process creates tremendous disk contention and draws on memory.
The Enterprise Edition performs an Enhanced Read-ahead and Scan a little differently. Unlike with the non Enterprise Edition versions, when UserA issues the SELECT * FROM Customer command, the Enterprise Edition begins scanning the Customer table. When UserB issues the same command 20 seconds later, the table scan for UserB starts exactly where UserA is currently reading. UserA and UserB's queries will both read the last page of the Customers table at about the same time, but then UserB's scan will go back to the beginning of the Customer table to scan the pages that UserA had scanned before UserB began its query. This process dramatically reduces disk contention and the draw on memory.