SQL Where Clause Against View

I have a view (actually, it's a table valued function, but the observed behavior is the same in both) that inner jo开发者_如何学Cins and left outer joins several other tables. When I query this view with a where clause similar to

SELECT *
FROM [v_MyView]
WHERE [Name] like '%Doe, John%'

... the query is very slow, but if I do the following...

SELECT *
FROM [v_MyView]
WHERE [ID] in 
(
    SELECT [ID]
    FROM [v_MyView]
    WHERE [Name] like '%Doe, John%'
)

it is MUCH faster. The first query is taking at least 2 minutes to return, if not longer where the second query will return in less than 5 seconds.

Any suggestions on how I can improve this? If I run the whole command as one SQL statement (without the use of a view) it is very fast as well. I believe this result is because of how a view should behave as a table in that if a view has OUTER JOINS, GROUP BYS or TOP ##, if the where clause was interpreted prior to vs after the execution of the view, the results could differ. My question is why wouldn't SQL optimize my first query to something as efficient as my second query?

EDIT

So, I was working on coming up with an example and was going to use the generally available AdventureWorks database as a backbone. While replicating my situation (which is really debugging a slow process that someone else developed, aren't they all?) I was unable to get the same results. Looking further into the query I am debugging, I realized the issue might be related to the extensive use of User Defined Scalar Valued Functions. There is heavy use of a "GetDisplayName" function that depending upon the values you pass in, it will format lastname, firstname or firstname lastname etc. If I simply omit that function and do the string formatting in the main query/TVF/view or whatever, performance is great. When looking at the execution plan, it didn't give me a clue to look at this as the issue which is why I initially ignored it.

The scalar UDFs are very likely the issue. As soon as they go into your query you've got a RBAR execution plan. It's tolerable if they're in the SELECT but if they're being used in a WHERE or JOIN clause....

A pity because they can be very useful but they're performance killers in big SELECTs and I'd suggest trying to rewrite either the UDFs to table valued or the query to avoid the UDFs, if at all possible.

Though I'm not SQL guru but most probably it is due to fact that in second query you are selecting only one column that makes it faster and secondly ID column seems to be some key and thus indexed. This can be the reason why it is faster the second way.

First Query:

SELECT * FROM [v_MyView] WHERE [Name] like '%Doe, John%'

Second query:

SELECT * FROM [v_MyView] WHERE [ID] in  
(SELECT [ID] FROM [v_MyView] WHERE [Name] like '%Doe, John%')