How is it possible to use Index Seek for LIKE %search-string% case?

Question

Hello,
I have the following SP:
CREATE PROCEDURE dbo.USP_SAMPLE_PROCEDURE(@Beginning nvarchar(15))
AS
SELECT * FROM HumanResources.Employee
WHERE NationalIDNumber LIKE @Beginning + N'%';
GO
If I run the sp first time with param: N'94', then the following plan is generated and added to the cache:
SQL Server "sniffs" the input value (94) when compiling the query. So for this param using Index Seek for AK_Employee_NationalIDNumber index will be the best option. On the other hand, the query plan should be generic enough to be able to handle
any values specified in the @Beginning param.
If I call the sp with @Beginning =N'%94':
EXEC dbo.USP_SAMPLE_PROCEDURE N'%94'
I see the same execution plan as above. The question is how is it possible to reuse this execution plan in this case? To be more precise, how
Index Seek can be used in case LIKE %search-string% case. I expected that
ONLY Index Scan operation can be used here.
Alexey

Answer 1

The key is that the index seek operator includes both seek (greater than and less than) and a predicate (LIKE).  With the leading wildcard, the seek is effectively returning all rows just like a scan and the filter returns only rows matching
the LIKE expression.
Do you want to say that in case of leading wildcard, expressions Expr1007 and Expr1008 (see image below) calculated such a way that
Seek Predicates retrieve all rows from the index. And only
Predicate does the real job by taking only rows matching the Like expression? If this is the case, then it explains how
Index Seek can be used to resolve such queries: LIKE N'%94'.
However, it leads me to another question: Since
Index Seek in
this particular case scans
all the rows, what is the difference between
Index Seek and Index Scan?
According to
MSDN:
The Index Seek operator uses the seeking ability of indexes to retrieve rows from a nonclustered index.
The storage engine uses the index to process
only those rows that satisfy the SEEK:() predicate. It optionally may include a WHERE:() predicate, which the storage engine will evaluate against all rows that satisfy the SEEK:() predicate (it does not use the indexes to do this).
The Index Scan operator retrieves
all rows from the nonclustered index specified in the Argument column. If an optional WHERE:() predicate appears in the Argument column, only those rows that satisfy the predicate are returned.
It seems like Index Scan is a special case of Index Seek,
which means that when we see Index Seek in the execution plan, it does NOT mean that storage engine does NOT scan all rows. Right?
Alexey