Таким образом, моя проблема заключалась в том, что SP, в котором я реализовал это, получит относительно неструктурированные данные, а затем попытается применить к ним сортировку и фильтрацию.Чтобы выжать из этого максимальную производительность, нам пришлось делать такие вещи, как иногда заполнение табличной переменной @ FOO1, но затем иногда применять к ней сортировку или фильтрацию с результатами, идущими в @ FOO2, прежде чем соединять ее с реальной таблицей данных, чтобы получить дополнительный столбецданные.Если бы производительность не была такой уж большой проблемой, я бы выбрал более простой вариант - просто создать переменную @FOOFinal, в которую будут помещены все данные, до реализации одного JOIN для получения оставшихся данных.Но INSERT INTO @FOOFinal SELECT * FROM @ FOO1 (например) стоит драгоценных миллисекунд, так что это неприемлемо.
В конечном счете, решение было просто создать отдельный SP, в котором мы выполняем JOIN из такогоТаблица Переменная к другим данным.Поскольку переменная Table была определена как тип табличной переменной, мы могли (благодаря тому факту, что мы больше не поддерживаем ничего более старого, чем SQL Server 2008), использовать Table Type в качестве параметра в SP.Таким образом, решение состоит в том, чтобы просто вызвать этот SP с @ FOO1 или @ FOO2 в качестве передаваемого параметра, и это устраняет необходимость назначать один другому.