2 回答
看来你已经考虑了很多。不管我或其他人怎么说，唯一确定的方法就是自己测量。在这种情况下，这不再是一个 SQL Azure 问题，而是一个一般的 SQL Server 查询优化问题。
对于您的情况，有一些提示可以帮助您入门。当您使用 LINQ 时，您无法直接访问在 SQL 中运行的实际查询。您可能认为您知道查询应该是什么样子，但根据您使用的 EF 版本，它可以就如何构建查询做出一些有趣的决定。要准确找出正在运行的查询，您需要使用 SQL Profiler 或Extended Events。SQL Profiler 不适用于 SQL Azure，因此您需要使用扩展事件或在某处的本地服务器上获取数据库的副本并运行指向本地的应用程序。SQL Server Management Studio (SSMS) 中的导出数据层应用程序和相关导入对此非常有用。
然后，您可以使用实际查询在 SSMS 中针对 Azure 中的数据库运行它们以获取执行计划。然后，您可以更改索引，再次运行查询并比较计划。如果您不想弄乱您的主要开发数据库，您可以通过多种方式轻松创建副本，包括使用CREATE DATABASE xxx AS COPY OF yyyy命令。
不要试图对本地数据库进行优化。SQL Azure 的性能大纲与大多数本地 SQL 安装不同。
综上所述，如果所有查询都将始终包含租户 ID，那么是的，我希望将其作为聚集索引的第一部分包含在内会提高查询性能。对于所有其他指标，我不太确定，所以我会测量、测量、测量。还要记住，索引不是免费的，您创建的每个索引都会影响您的写入性能以及数据库的大小，因此我不会发疯并索引所有内容。
最后，不要担心为您的 PK 使用 guid，如果您的数据库变得足够大以至于您需要通过租户 ID 联合它（您的结构看起来可以很好地处理它） IDENTITY 列不再成为一种选择。
I agree with the answer by @knigtpfhor, but would add that if you intend to use Federations in SQL Azure you'll need to include the Federation Key (TenantID) as part of the clustered index on each table in the Federation Member. (Your Option # 2 above). See Federation Guidelines and Limitations for more details.
I would absolutely add additional nonclustered indexes on your tables; choosing the fields to index on is a bit of science and a bit of an art, but I generally try to start by reviewing the queries I am likely to issue and make sure I have an index that covers the fields in question. My hunch is that while your Primary \ Foreign Keys are indexed, they probably don't correlate in all cases to how you actually query for data.
What sort of performance issues are you experiencing? Are you having issues writing data or querying data or both? How big is the database in question? Are your performance issues intermittent or fairly consistent?