将SQL Server与 * 任何 * 其他产品一起运行都是不明智的，包括SQL Server的另一个示例。提出此建议的原因是SQL Server使用操作系统资源的方式的本质。SQL Server在名为SQLOS的用户模式内存管理和处理器调度基础结构上运行。SQL Server旨在以最佳性能运行，并假定它是操作系统上的唯一服务器。因此，SQL OS为SQL进程保留机器上的所有RAM，并为每个CPU核心创建调度程序，并在需要时利用其可以获得的所有CPU为所有调度程序分配任务以运行。由于SQL保留所有内存，因此需要内存的其他进程将导致SQL看到memory pressure，并且对内存压力的响应将从缓冲池中逐出页面，并从计划缓存中逐出已编译的计划。（有传言说下一代Exchange也会），SQL是唯一一个实际上会缩小的进程，以便给其他进程（比如漏洞百出的ASP池）提供空间。Dynamic Memory Management.
CPU调度也会出现类似的情况，即其他进程从SQL调度程序中窃取CPU时间。在高端系统和Opteron计算机上，情况会变得更糟，因为SQL充分利用NUMA局部性，但其他进程通常都知道NUMA，而且，尽管操作系统可以尝试保持分配的局部性，它们最终分配了整个物理RAM，并降低了系统的总吞吐量，因为CPU在等待跨numa边界页面访问时处于空闲状态。还有其他一些事情也需要考虑，例如由于其他进程占用CPU周期而导致TLB和L2未命中增加。
总而言之，你可以在SQL Server上运行其他服务器，但不推荐。如果你必须这样做，那么请确保尽你所能隔离这两个服务器。对SQL和IIS/ASP使用CPU关联掩码，以将两者隔离在不同的核心上，配置SQL以保留较少的RAM，从而为IIS/ASP留下空闲内存。将应用程序池配置为主动回收，以防止应用程序池增长。

是的，这是可能的，许多人都这样做了。
这往往是安全性和/或性能的问题。
安全性受到质疑，因为你的攻击面增加了一个盒子，有这两个。也许不是一个问题，你。
性能是有问题的，因为现在你的服务器正在服务web和DB请求。同样，也许在你的情况下不是问题。
测试与生产....
许多人在测试环境中可能感觉良好，但在生产环境中则不然....
同样，这取决于您的团队。如果可能的话，我希望我的测试和生产环境尽可能相似，但这是我的偏好。

有可能，是的。
对于生产环境来说，这是个好主意。
您将遇到的问题是，SQL Server数据库在高负载下很可能会执行繁重的磁盘I/O操作，并占用大量内存。这种组合将占用计算机，您将看到IIS在尝试提供页面时的性能下降。

在某些情况下这是不明智的...在其他情况下完全明智。
如果您的计算机未得到充分利用，不会遇到繁重的负载，那么在同一台计算机上安装数据库是有好处的，因为您不必通过网络传输任何数据。
另一方面，如果IIS或数据库中的一个或两个负载很重，则它们很可能会开始产生干扰，并且专用硬件的性能增益可能会超过必须通过网络传输的损失。

不要忘记维护问题...你不能重启/修补一个而不破坏另一个。如果它们在两个盒子上，你可以给予你的用户一个更好的体验，而不是如果你在维护SQL盒子，网络服务器没有响应。
不是最高的名单，但应该注意。

当然可以。例如，如果您的用户群很大，或者正在对数据库运行大量繁重的查询，您就会遇到性能问题。我曾在多个运行IIS和SQL Server的站点上工作过，这些站点通常位于1和1（快递！）在同一个盒子上与数千名用户（数百条并发）和数百万条记录在设计糟糕的表中，通过编写糟糕的存储过程访问，用户体验当然是可以忍受的。