split表的时候发现start key或end key后缀居然不是纯数字86999b907e8ac02800，这怎么搞啊。
直接查看主键的最大最小值 min/max，然后再拆分。
主键区间拆分：查询主键字段最大、最小值，依据主键值域均匀划分区间完成 Region 预拆分，不受数据容量与业务访问负载约束。
直接查分区真实数据边界，原样复制 key 字符，照着内容执行 split 拆分就行。
这个问题可以看看官方文档的 FAQ，TiDB 在这块有比较详细的说明。方便的话贴一下具体的报错日志，方便大家帮忙定位。
一张表同时存在【行数据 Region + 多个二级索引 Region + 全局索引 Region】，三类 key 混在一起，所以 split 不能直接写数字切分
直接填入完整内部 start_key/end_key 手工切分
“带字母的非纯数字后缀” 和 “纯数字后缀” 本质上是同一种 row_id 的两种不同显示格式
可以将他转化为十进制 SELECT CAST(CONV(‘86999b907e8ac028’, 16, 10) AS SIGNED);
带字母的是十六进制，TIDB不会转化为十进制的
从数据库设计角度，这类问题通常可以归结为数据模型和访问模式的匹配度问题。具体需要看你的 schema 和查询模式才能给出更针对性的建议。
试试这种方法：
SPLIT TABLE 表名 BETWEEN ‘t_16338_r_86999b907e8ac02800’ AND ‘t_16338r_477940550470539269’ INTO 分片数;
TiDB 的 start_key/end_key 是编码后的 KV 键，不是纯数字。
用 TIDB_DECODE_KEY() 可还原原始值。
Split 直接用表 / 索引语法即可，无需操作编码后的 Key。
需要带key才可以的。
mysql>
mysql> split table reg REGIONS 16;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your TiDB version for the right syntax to use line 1 column 23 near “REGIONS 16”
mysql> split table reg;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your TiDB version for the right syntax to use line 1 column 15 near “”
这种手工分割还要自己计算step的操作真的是低级，这些活就应该代码自动完成，不是人为去计算。
最好的方法只能是重建表，加参数了，一劳永兔
展示的 START_KEY 是 TiDB 内部十六进制编码串，带字母是正常格式，不能直接整条拿来拆分。