ddl: check the key existence on original index (#40749)

[ti-chi-bot]

This is an automated cherry-pick of #40749

What problem does this PR solve?

Issue Number: close #40730

Problem Summary:

create table t(a int default 0, b int default 0);
alter table t add unique index idx(a);

-- delete-only
insert into t values (5, 5);
-- rows    = [h1 -> (5, 5)]
-- idx     = []
-- tmp_idx = []
-- It writes nothing to the index or temp index because of the delete-only state.

-- write-only
insert into t values (5, 7);
-- rows    = [h1 -> (5, 5), h2 -> (5, 7)]
-- idx     = []
-- tmp_idx = [5 -> h2]
-- It is redirected to the temp index for write-only state.

delete from t where b = 7;
-- rows    = [h1 -> (5, 5)]
-- idx     = []
-- tmp_idx = [5 -> h2d]
-- It is redirected to the temp index for write-only state.
-- The delete operation is converted to a deletion marker(h2d).

-- write-reorg, backfill
-- rows    = [h1 -> (5, 5)]
-- idx     = [5 -> h1]
-- tmp_idx = [5 -> h2d]

-- write-reorg, after merging
insert into t values(5, 9);
-- rows    = [h1 -> (5, 5), h3 -> (5, 9)]
-- idx     = [5 -> h1]   + 5 -> h3
-- tmp_idx = [5 -> h2d]  + 5 -> h3
-- Double write. New changes are written to both index and temp index (+ 5 -> h3).
-- When TiDB checks the unique constraint, "h2d" is found as the deleted marker and the flag of "presume key exists" is incorrectly unset.
-- Finally, these two records are overwritten.

-- rows    = [h1 -> (5, 5), h3 -> (5, 9)]
-- idx     = [5 -> h3]
-- tmp_idx = [5 -> h3]

-- public
admin check table t;
-- [admin:8223]data inconsistency in table: t, index: idx, handle: 1, index-values:"handle: 3, values: [KindInt64 5]" != record-values:"handle: 1, values: [KindInt64 5]"

The problem happens on the unique check. A deletion marker on temporary index doesn't mean the corresponding row record is deleted.

What is changed and how it works?

Because the last DML in above issue happens in the final stage of adding index, there is no way to "detect" duplicated keys after the insertion. In other words, this DML must report a key duplicated error. Thus, we have to correct the key uniqueness check mechanism when TiDB writes to temp index. This is also crucial to DML like REPLACE and INSERT ON DUPLICATE UPDATE because the uniqueness determines the semantic of the following action.

Here is the new uniqueness check introduced in this PR:

func key_is_unique(temp_index_key, handle) bool {
    temp_val = get(temp_index_key)
    if temp_val == nil {
        val := get(index_key)
        if val == nil {
            return is_unique
        } else {
            return not_unique
        }
    } else if temp_val == delete_marker {
        val = get(index_key)
        if val == nil {
            return is_unique
        } else {
            deleted_handle = decode_handle(temp_val)
            index_handle = decode_handle(val)
            if deleted_handle == index_handle {
                return is_unique
            }
            row_key = encode(index_handle)
            row_val = get(row_key)
            if row_val == nil {
                return is_unique
            } else {
                return not_unique
            }
        }
    } else {
        return not_unique
    }
}

The second change is about the encoding of temp index value.

When there are multiple insertions or deletions to the temp index, TiDB always overwrites the previous value in current implementation. This may cause some of the user changes lost and data-index inconsistency. Several test cases in this PR show the problems.

This PR introduces a new temp index value encoding, storing all the insertion/deletion history by appending new value to existing value. In the merge process, the temp index merge worker extracts the operations in temp index value, and replay them to the index.

// TempIndexValue is the value of temporary index.
// It contains one or more element, each element represents a history index operations on the original index.
// A temp index value element is encoded as one of:
//   - [flag 1 byte][value_length 2 bytes ] [value value_len bytes]   [key_version 1 byte] {distinct normal}
//   - [flag 1 byte][value value_len bytes]                           [key_version 1 byte] {non-distinct normal}
//   - [flag 1 byte][handle_length 2 bytes] [handle handle_len bytes] [key_version 1 byte] {distinct deleted}
//   - [flag 1 byte]                                                  [key_version 1 byte] {non-distinct deleted}

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)
• No code

Side effects

• Performance regression: Consumes more CPU
• Performance regression: Consumes more Memory
• Breaking backward compatibility

Documentation

• Affects user behaviors
• Contains syntax changes
• Contains variable changes
• Contains experimental features
• Changes MySQL compatibility

Release note

Please refer to Release Notes Language Style Guide to write a quality release note.

Fix data inconsistency issue after adding unique index.

[ti-chi-bot]

[REVIEW NOTIFICATION]

This pull request has been approved by:

• Benjamin2037
• wjhuang2016

To complete the pull request process, please ask the reviewers in the list to review by filling /cc @reviewer in the comment.
After your PR has acquired the required number of LGTMs, you can assign this pull request to the committer in the list by filling /assign @committer in the comment to help you merge this pull request.

The full list of commands accepted by this bot can be found here.

Reviewer can indicate their review by submitting an approval review.
Reviewer can cancel approval by submitting a request changes review.

[wuhuizuo]

/hold high priority for trunk branch

[ti-chi-bot]

/unhold

[tangenta]

/retest

[Benjamin2037]

LGTM

[tangenta]

/merge

[ti-chi-bot]

This pull request has been accepted and is ready to merge.

Commit hash: 4238b02