admin recover index miss some rows

[3pointer]

Bug Report

Please answer these questions before submitting your issue. Thanks!

1. Minimal reproduce step (Required)

MySQL [test]>  create table t(id bigint(20) primary key, col varchar(255) unique key);
Query OK, 0 rows affected (0.10 sec)

MySQL [test]> insert into t values(9223372036854775807, "test");
Query OK, 1 row affected (0.01 sec)

MySQL [test]> admin recover index t col;
+-------------+------------+
| ADDED_COUNT | SCAN_COUNT |
+-------------+------------+
|           0 |          0 |
+-------------+------------+
1 row in set (0.00 sec)

2. What did you expect to see? (Required)

SCAN_COUNT should be 1.

3. What did you see instead (Required)

### 4. What is your TiDB version? (Required)

master

[3pointer]

The root cause is here.
codec.EncodeKey(sctx, nil, types.MaxValueDatum() is the byte 250 which is not the unlimited end key.

For intHandle it should becodec.EncodeInt(nil, math.MaxInt64)

[wjhuang2016]

The root cause is here. codec.EncodeKey(sctx, nil, types.MaxValueDatum() is the byte 250 which is not the unlimited end key.

For intHandle it should becodec.EncodeInt(nil, math.MaxInt64)

250 is fine, since we compare data by its prefix.
The problem is that in our implementation:

// 1. unique-key is duplicate and the handle is equal, skip it.
// 2. unique-key is duplicate and the handle is not equal, data is not consistent, log it and skip it.
// 3. non-unique-key is duplicate, skip it.

According to "unique-key is duplicate and the handle is equal, skip it.", the scan row is skipped. We don't count for that.
It's not a bug, but I still think we can improve it.

[3pointer]

The root cause is here. codec.EncodeKey(sctx, nil, types.MaxValueDatum() is the byte 250 which is not the unlimited end key.
For intHandle it should becodec.EncodeInt(nil, math.MaxInt64)

250 is fine, since we compare data by its prefix. The problem is that in our implementation:

// 1. unique-key is duplicate and the handle is equal, skip it.
// 2. unique-key is duplicate and the handle is not equal, data is not consistent, log it and skip it.
// 3. non-unique-key is duplicate, skip it.

According to "unique-key is duplicate and the handle is equal, skip it.", the scan row is skipped. We don't count for that. It's not a bug, but I still think we can improve it.

I don't think so.
the scanRowCount has been added in fetchRecoverRows

tidb/executor/admin.go

Line 385 in 9c64224

result.scanRowCount++

whether skip or not, it will be recorded.

you can try add another record and the SCAN_COUNT will be 1. (which should be 2)