Scan Count of a query increased from 1 to 2,226 after creating a non-clustered index

On my query 1st time it was taking almost 39 seconds and showing me non-clustered index is missing and


Scan count 1, logical reads 14553, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob
read-ahead reads 0

After Creating the non-clustered index the duration of the query execution comes down to 1sec and it's showing


Scan count 2266, logical reads 4539, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob
read-ahead reads 0

Logical reads is decreased after creating the non-clustered index, but Scan count increased to 2266. So my question is the performance of the query is developed or the Scan count 2266 make my query non-optimal?

First scenario, it's scanning the whole table and looking through 14553 pages of data. Second scenario, it's doing 2266 seeks (but counted as range scans) which each look at just 2 pages. So the second one is way better. Plus, many of those seeks will probably be looking at pages which have just been looked at, so on a cold cache it will be an even larger performance benefit. And, the second is more likely to parallelise better, being lots of small operations rather than a large one (which could still be parallelised, but it's more effort).

StackExchange Database Administrators Q#123517, answer score: 4