从PD-CTL读取到的region的startKey 和 endKey为什么包含0xff信息

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:
【 TiDB 使用环境】

【概述】 场景 + 问题概述

【应用框架及开发适配业务逻辑】

【背景】 做过哪些操作

【现象】 业务和数据库现象

【问题】 当前遇到的问题
由于业务需要需要读取到集群中所有的region的startKey和endKey,但是读取到的key中被加入了挺多0xff,如下:
“start_key”: “\xfftest\\uc\xffc-test\\\xff7/E83061\xff834_1_20\xff21112212\xff4554-E83\xff061834-1\xff-10002-2\xff-1-3\\168\xff09187711\xff15983493\xff7\x00\x00\x00\x00\x00\x00\x00\xf8”,
“end_key”: “\xfftest\\uc\xffc-test\\\xff7/E83068\xff320_1_20\xff21110511\xff0128-E83\xff068320-1\xff-10002-2\xff-1-4\\168\xff10662774\xff26292881\xff5\x00\x00\x00\x00\x00\x00\x00\xf8”,
【业务影响】
这个key信息和存储在tikv中的key不一致,无法进行比较
【TiDB 版本】 v2.1.8

【附件】 相关日志及监控(https://metricstool.pingcap.com/)


若提问为性能优化、故障排查类问题,请下载脚本运行。终端输出的打印结果,请务必全选并复制粘贴上传。

这里是做过相关的处理的,需要根据PD key Type,来进行解码

解码参考这个:
https://docs.pingcap.com/zh/tidb/stable/pd-control#region-key---formatrawencodehex-key

好的,已解决,谢谢

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。