Support splitting table by raw key
- Dominant language
- Go
- Stars
- 40.5k
- Forks
- 6.2k
- PR merge metrics
- PR metrics pending
Description
## Feature Request
**Is your feature request related to a problem? Please describe:**
In the scenario of heavy read/write workload, sometimes there is a hot spot in a specific region. To avoid the performance degrading, the hot spot region should be split. However, due to some reasons, PD is unable to split the region automatically, the users have to split it manually.
Here are the general steps:
1. Decode the region start key and end key with the builtin function `tidb_decode_key()`. Usually it produces a JSON format value that contains the row_id or index values. For example, we get index values `{1, "aaa"}` and `{100, "bbb"}`.
2. Calculate the appropriate split values. For example, we have `{33, ""}` and `{66, ""}`.
3. Split the region through `SPLIT TABLE` statement. In this example, the `SPLIT` statement looks like `SPLIT TABLE t INDEX idx BY (33, ""), (66, "");`
However, in the following cases, the start/end keys of regions are not always decodable:
- Clustered-index tables that need restored data.
- The tables that have been split with `SPLIT BETWEEN REGIONS`.
- ...
**Describe the feature you'd like:**
Support a new syntax like
```sql
SPLIT TABLE `t` BY RAW ('74800000000000009F5F72013XXX'), ('74800000000000009F5F72013YYY');
SPLIT TABLE `t` INDEX `idx` BY RAW ('74800000000000009F5F72013XXX'), ('74800000000000009F5F72013YYY');
```
It would be convenient to split the region without decoding it.
Note that the key should be validated to make sure it is operating on a correct table/index.
**Describe alternatives you've considered:**
https://github.com/pingcap/tidb/issues/35720 proposes to read the row by specifying the raw key so that the result could be used in `SPLIT BETWEEN/BY`, but I think it is a bit tedious. Moreover, if the row does not exist, the issue is not resolved.
**Teachability, Documentation, Adoption, Migration Strategy:**
TBD
Contributor guide
Assessment
This issue has not been assessed yet.