Single vs Multiple Field Indexes

Context:

In Couchbase Lite (via the Swift SDK), suppose I have model objects like this:

class Song
{
    var title: String
    var normalizedTitle: String

    var artist: String
    var normalizedArtist: String

    var durationInSeconds: Int
}

Where the normalized version of certain properties have been forced to lowercase, stripped of diacritics, and standardized for multi-byte characters so that I can perform an exact equality test rather than a case-insensitive search.

I need to query Song objects that match (exactly) a given title, artist, and duration. So I create an index on normalizedTitle, normalizedArtist, and durationInSeconds.

Question:

That same index will cover cases where I query for any one of the fields included in the index, correct? So if I want to match for just title, the index will still be used even though it includes other fields?

Is there any advantage to having an additional single-field index if a multi-field index already exists?

Does the order of the fields in the multi-field index matter when I create the index? (For example, is it better to create the index with durationInSeconds as the first field because that’s a faster value to test than potentially long strings for the other two fields?)

I understand the general guidance about “don’t create indexes needlessly; they slow down writes.” But is there practical advice for an upper limit on the number of fields in a single index?

2 posts - 2 participants

Read full topic