>>If you need an index on a logical field or on deleted(), make sure to add the Binary keyword when you create it. That will make the index much smaller, meaning much faster.
>
>Not faster than not having the index at all, especially when other filters have already identified the records.

When binary came out, we measured perf with traditional, binary and no index on deleted() on sizable data sets of a real application, as I already had a test harness based on QueryPerf in place. We weighed the results of the different data sets to the largest, as runtime duration was rising more than linear.

Binary was the best compromize, leading to smallest total time and no really bad performance in single measurements -
was never the worst / an outlier. IIRC we added a more than a dozen binary indices to tables where we had previously deleted a traditional index on deleted() - after running perf tests, total table count > 300.

YMMV
>
>>
>>>The more it makes sense for me to get rid of it. Thank you.
>>>
>>>>Any index on a binary value will generally not be very effective. I've heard some people say that an index on DELETED() is effective if you have a high number of deleted records, but never tested this myself.
>>>>
>>>>