In my case the leading column in the index is unique ... it strikes me it has all the information to know its unique.
It does not. That primary key does not guarantee that either
b are unique, just that all combinations of
b are. There could be many rows for which
b = 1 is true, maybe all of them, maybe none of them. When you search for a specific combination of
b then it can use the index to do a simple seek.
With that table definition, your first query is like asking "find all words in the dictionary where the second letter is 'a'". You can't answer that with a single seek. Your second query is like asking for "words starting 'aa'" which is easy to answer with that index.
Note though that some database systems are able to perform a skip-search to speed up the first query, which would help here, essentially looking for
a=1 and b=1 then
a=2 and b=1 then
a=3 and b=1 and so on (it isn't quite this but as near to as makes little odds). If operation is supported it may be used if the datatype of
a and the selectivity indicated by the index stats suggest it might be appropriate. No version of SQL server supports this operation though. Oracle does unless you have a really old version (> a decade or two), as does SQLite, IIRC both call the operation a "skip scan". Further note that in every circumstance where a skip-scan is better than a full index scan, having an index on the second column to use would be more efficient, often significantly so, meaning that while the feature might make some queries better in databases that are not optimised for them, if you expect such queries you should optimise your table(s) for them by having the extra index even if your DBMS supports skip-searches.
it uses some other NC index
To explain why that particular index is selected and used instead of any other, we would need to know how that index and all the other indexes are defined, and perhaps see the query plan. Also you don't say how the index is used - I assume it was scanned rather than being used for seeks.