Это зависит:
1) Если вид не индексируется, то вид расширяется
-- View definition
CREATE VIEW Sales.v_SalesOrderDetail
AS
SELECT h.SalesOrderID, h.SalesOrderNumber, h.OrderDate,
d.SalesOrderDetailID, d.OrderQty, d.UnitPrice, d.LineTotal,
p.ProductID, p.Name AS ProductName, p.Color AS ProductColor
FROM Sales.SalesOrderHeader h
INNER JOIN Sales.SalesOrderDetail d ON h.SalesOrderID = d.SalesOrderID
INNER JOIN Production.Product p ON d.ProductID = p.ProductID
GO
-- View usage
SELECT v.SalesOrderDetailID, v.OrderQty, v.UnitPrice, v.ProductName
FROM Sales.v_SalesOrderDetail v
WHERE v.ProductColor='Red';
GO
Если посмотреть на план выполнения (SSMS: Ctrl + M), 
затем мы увидим, что вид (FROM Sales.v_SalesOrderDetail v) расширен и сервер запрашивает только две таблицы: Sales.SalesOrderDetail d и Production.Product p. Более того, мы можем видеть, как соединение между Sales.SalesOrderHeader h и Sales.SalesOrderDetail d удаляется, потому что:
оговорка SELECT (SELECT v.SalesOrderDetailID, v.OrderQty, v.UnitPrice, v.ProductName) не включает в себя столбцы из таблицы Sales.SalesOrderHeader,
между этим двумя столовыми есть ограничение внешнего ключа и
Это ограничение FK является надежным.
2) Если вид индексируется (это означает, что существует UNIQUE CLUSTERED INDEX определен на представлении) и издание SQL Server является предприятие, то вид может быть расширен или нет. Если издание <> предприятие, то индексированное представление расширяется.Мы можем заставить сервер для не расширяют в [индексированный] вида с помощью NOEXPAND намека:
-- View definition
CREATE VIEW Sales.v_SalesOrderDetail2
WITH SCHEMABINDING
AS
SELECT h.SalesOrderID, h.SalesOrderNumber, h.OrderDate,
d.SalesOrderDetailID, d.OrderQty, d.UnitPrice, d.LineTotal,
p.ProductID, p.Name AS ProductName, p.Color AS ProductColor
FROM Sales.SalesOrderHeader h
INNER JOIN Sales.SalesOrderDetail d ON h.SalesOrderID = d.SalesOrderID
INNER JOIN Production.Product p ON d.ProductID = p.ProductID
GO
-- Defining the UNIQUE CLUSTERED INDEX
CREATE UNIQUE CLUSTERED INDEX PK_v_SalesOrderDetail2
ON Sales.v_SalesOrderDetail2 (SalesOrderDetailID);
GO
-- View usage
SELECT v.SalesOrderDetailID, v.OrderQty, v.UnitPrice, v.ProductName
FROM Sales.v_SalesOrderDetail2 v WITH (NOEXPAND)
WHERE v.ProductColor='Red';
GO
В этом случае, мы можем видеть, что план выполнения 
включает оператор Clustered Index Scan PK_v_SalesOrderDetail2. Таким образом, он использует индекс, определенный на втором представлении.
Знайте: SQL Server bug indexed view + MERGE.
Оба ответа точны. Представление, по существу, сокращает использование подзапроса в соединении. Существует ряд причин, по которым могут возникать ваши тайм-ауты; поскольку вы сказали, что тайм-аут, а не тупик, я предполагаю, что вставки вызывается из-за пределов SQL. Можете ли вы предоставить дополнительную информацию о том, как происходят таймауты? Возможно, у вас слишком низкий порог тайм-аута (например, с объектом SqlCommand). –
Я довольно большой противник использования просмотров в сохраненном коде. Если вы можете использовать представление, вы также можете записать соединения вручную, а не использовать представление. Проблема с представлением заключается в том, что вы пытаетесь использовать одностановичное решение для сценариев, которые, скорее всего, не требуют полного решения. Имейте в виду, что SQL очень хорошо оптимизирует себя, и это делается на основе используемых таблиц и конкретных столбцов, используемых из каждой таблицы. Если ваше представление возвращает 6 столбцов, но вам нужно всего четыре, тогда ваш запрос по своей сути неэффективен из-за представления. –
@ Love2Learn - не совсем так. Если вы выбираете только 4 столбца из представления, оптимизатор может использовать эту информацию и создавать план, который не сможет предоставить другие столбцы, если такой план является жизнеспособным. Как я уже сказал, они оптимизируются во всем запросе (с расширением представлений в нем). –