I know, this is not the ideal index, although in the real production use case it is fine and does not need to be optimized further; the cost and effort would not result in enough improvement to be worth it. The point of this post was simply to show readers how to figure out what the execution plan is doing in some cases.

one more issue can make idx_intcol more effective.
the url-int index is very big one (each node need to contain a lot of chars (which i can assume that the beginning is quite the same “http://aaa.bbb.com/blablka”.
this issue cause to a very “deep” index which require a lot of reading in the index tree.
the small int is a much smaller index, and the needs for IS NULL (or not exist in the EXPLAIN) makes the search easier since it not need to read the actual data.

i.e. if it will not find the int – the row matches.
if it does, it will go to the rows which has the same in and check the url…

Can you can post the EXPLAIN after the charset change?