当不是所有代码都是异步的时候，异步web服务的好处是什么?

在服务器端，部分async解决方案通常没有任何好处。

1) Web Api支持异步操作方法，但如果我在处理请求时做同步数据库调用，那么线程阻塞在调用上，我将无法获得异步可以给我更好的线程经济的好处或什么?

正确的。一旦执行同步(阻塞)数据库调用，就会在该调用期间占用线程。因此，您从async中获得的好处不适用。

2)如果我有一个同步的ServiceStack服务调用等待一个异步数据库调用，那么会发生什么?我假设一个线程是为处理整个同步http请求而保留的，当这个线程等待异步调用时，它仍然保留给web请求或什么?

这与同步数据库调用相同。在后台，同步数据库调用异步执行实际的调用，然后阻塞调用线程，直到调用完成。所以你仍然有一个线程在调用期间被阻塞，你没有得到任何async的好处。

基本上，我的问题可以归结为:如果不是所有的IO调用都是异步的，是否有任何理由使用异步?

还有一些更模糊的场景。您可以使用Task.WhenAll执行有限类型的并发，使用async要比使用其他形式的异步并发容易得多。但这是我能想到的唯一好处，如果你没有一个完整的- async堆栈

这基本上归结为调用代码可以做什么，而异步调用正在进行。您的第一个示例很适合这种情况。当调用保存方法时，UI可以做其他事情。在方法的幕后发生了什么并不重要……控制权已被交还给应用程序以继续它的方式。

你的第二个例子只是意味着服务栈服务可以在异步数据库调用完成时做一些事情。但是如果它不做任何事情，那么就没有任何真正的理由来使用异步调用。

异步方法在其工作负载期间做什么并不重要，重要的是调用应用程序在调用期间可以做什么。