首先：不要过早优化!这意味着：不要为了你不知道好处而牺牲你代码的简单性和可维护性。
让我们来看看。50000条记录并没有真正说明什么没有指定的记录大小。我会建议你从基本的实现和优化时需要的。所以试试这个
1.使用这50000条记录实现简单的JSON响应，并尝试从消费者应用程序调用它。测量数据大小和响应时间-仔细评估，这是否真的是一天一次操作的问题
1.如果是的话，打开JSON响应的压缩--这通常是JSON的巨大变化，因为有很多重复的文本。将内容类型标头设置为"application/javascript"-默认情况下，Azure为此内容类型启用动态压缩。请再次尝试，评估数据大小或响应时间是否有问题
1.如果它仍然是问题，也许它是一些序列化优化的时间毕竟，但我会strogly推荐一些标准和证明在这里（没有自定义CSV混乱），例如谷歌协议缓冲区：https://code.google.com/p/protobuf-net/

这个评论有点长，所以...
最好的方法很可能是那些“视情况而定”的答案之一。
仅仅是数据库在Azure上，还是你的整个主机都在Azure上。我自己从来没有在Azure上做过任何生产。
您试图优化什么--总的回合响应时间、总的服务器CPU时间，或者其他时间？
例如，如果您的数据库服务器是Azure，但Web服务器是本地的，那么您可以简单地优化数据库请求，并在需要时通过多个Web服务器进行扩展。
如果数据随着每个请求而改变，那么如果您试图优化服务器CPU负载，就不应该压缩它，但是如果您试图优化带宽使用，就应该压缩它--这两者都可能成为瓶颈/昂贵的资源。
对于50 K条记录，即使JSON也可能有点冗长。如果您的数据是单个表，则使用CSV之类的格式（如果没有其他格式，则将第一行作为记录头进行完整性检查）可能会节省大量数据。如果您的结果是连接多个表的结果，即层次结构，则建议使用JSON，以避免滚动您自己的层次结构表示的复杂性。
您是否使用SSL或您的Web服务器，如果是，SSL可能是您的瓶颈（除非通过其他硬件处理）
你发送的数据是什么性质的？主要是文本、数字还是图像？文本通常压缩得很好，数字压缩得不好，图像压缩得很差（通常）。既然你建议使用JSON，我希望你几乎没有二进制数据。
如果压缩JSON，它可能是一种非常有效的格式，因为重复的字段名称大多会从结果中压缩出来。XML也是如此（但标记成对出现的情况较少）
添加
如果您事先知道客户机将获取什么，并且可以提前准备数据包数据，请务必这样做（除非存储准备好的数据是个问题）。您可以在非高峰时间运行此操作，创建一个静态的.gz文件，并让IIS在需要时直接提供它。2你的API可以简单地分为两部分1）检索客户端可用的静态.gz文件列表2）确认处理所述文件，以便您可以删除它们。
想必您知道JSON和XML不像CSV那样脆弱，即从API中添加或删除字段通常很简单。因此，如果您可以压缩文件，您肯定应该使用JSON或XML -- XML对一些客户端来说更容易解析，老实说，如果您使用Json .NET或类似的工具，您可以从相同的定义和信息集生成任何一种，所以灵活性很好。就我个人而言，我非常喜欢Json.NET，简单快捷。

通常，这种大型请求需要分页，因此JSON响应中包含一个URL，用于请求下一批信息。
现在，下一个问题是您的客户端是什么？例如，浏览器还是后台应用程序。
如果是浏览器，则存在如下限制：http://www.ziggytech.net/technology/web-development/how-big-is-too-big-for-json/
如果它是一个应用程序，那么您当前在单个JSON调用中处理50，000个请求的方法是可以接受的，这里您唯一需要注意的是数据库上拉取记录的负载，特别是如果您有许多客户端。

如果你愿意使用第三方库，你可以试试Heavy-HTTP，它可以直接解决这个问题。（我是这个库的作者）