您可以尝试使用多步表值函数.这样，服务器就***将 TVF 的结果具体化到一个表变量中.此外，您在声明此表类型(PRIMARY KEY、UNIQUE、CHECK)时可以尝试使用声明性约束来提高最终查询的性能:

You could try using a multi-step table valued function. This way, the server is forced to materialize the TVF's results into a table variable. Also, you could try using declarative constraints when declaring the this table type (PRIMARY KEY, UNIQUE, CHECK) to improve the performance of the final query:

CREATE FUNCTION CocoJamboSchema.CocoJamboFunction(@parameters ...)
RETURNS @Results TABLE (
    Col1 INT NOT NULL,
    Col2 VARCHAR(10) NULL,
    ...
    PRIMARY KEY(Col1)
)
AS
BEGIN
    WITH MyCTE (...)
    AS
    (
        ...
    )
    INSERT @Results (...)
        FROM MyCTE;

    RETURN;
END;

SELECT ...
FROM CocoJamboSchema.CocoJamboFunction(param values) f
INNER JOIN MySchema.MyTable t ON f.Col1=t.Col1
ORDER BY t.Col1;

不要忘记将 ORDER BY 子句添加到您的最终查询中.

Don't forget to add the ORDER BY clause to your final query.

最近，我使用这个解决方案来优化另一个视图(ViewB)使用的视图(ViewA、DISTINCT + LEFT JOIN + GETDATE()).在这种情况下 (ViewA) 不可能创建索引视图(因为 DISTINCT + LEFT JOIN + GETDATE()).相反，我创建了一个多语句 TVF，它通过减少最终查询的逻辑读取(在某些情况下大幅减少)来提高性能.

Recently, I used this solution to optimize a view (ViewA, DISTINCT + LEFT JOIN + GETDATE()) used by another views (ViewB). In this case (ViewA) was impossible to create a indexed view (because of DISTINCT + LEFT JOIN + GETDATE()). Instead, I created a multi-statement TVF that improved the performance by reducing the logical reads (drasticaly in some cases) of the final query.

注意:当然，您可以尝试使用索引视图.