lighting导入后其他库出现大量的查询错误

Mingdr · 2026 年2 月 9 日 02:18

【 TiDB 使用环境】测试
【 TiDB 版本】8.5.4
【复现路径】执行了lighting导入
【遇到的问题：问题现象及影响】，导入到库1后，其他库的查询出现大量的错误：

tiup tidb-lightning -config lig.yml
SELECT  *  FROM d_permission
> 1105 - invalid data type: unsupported data type `128`

很多表都出现这个问题，没法具体查看是哪行数据，它直接报错了
导入的库和查询的库不是同一个，怎么会影响到其他库的数据呢
开始导入出了点问题，还执行过：

./tidb-lightning-ctl --checkpoint-error-destroy=all --config=/home/tidb/prvz/lig.yml
./tidb-lightning-ctl --checkpoint-error-destroy=all

导入的配置：

[tidb@master241 prvz]$ cat lig.yml
[lightning]
# 日志
level = "info"
file = "tidb-lightning.log"

[tikv-importer]
# 选择使用的导入模式
backend = "local"
# 设置排序的键值对的临时存放地址，目标路径需要是一个空目录
sorted-kv-dir = "/home/tidb/prvz"

[mydumper]
# 源数据目录。
data-source-dir = "/home/tidb/prvz/tivz"

# 配置通配符规则，默认规则会过滤 mysql、sys、INFORMATION_SCHEMA、PERFORMANCE_SCHEMA、METRICS_SCHEMA、INSPECTION_SCHEMA 系统数据库下的所有表
# 若不配置该项，导入系统表时会出现“找不到 schema”的异常
filter = ['*.*', '!mysql.*', '!sys.*', '!INFORMATION_SCHEMA.*', '!PERFORMANCE_SCHEMA.*', '!METRICS_SCHEMA.*', '!INSPECTION_SCHEMA.*']
[tidb]
# 目标集群的信息
host = "192.168.0.244"
port = 30003
user = "root"
password = ""
# 表架构信息在从 TiDB 的“状态端口”获取。
status-port = 30004
# 集群 pd 的地址。从 v7.6.0 开始支持设置多个地址。

xfworld · 2026 年2 月 9 日 02:37

这个和导入貌似没啥关系哦

Kongdom · 2026 年2 月 9 日 02:56

有空间类型的字段？

随缘天空 · 2026 年2 月 9 日 03:11

核心原因应该是TiDB 的元数据缓存被污染了，虽然你只导入了“库1”，但TiDB Lightning在导入过程中会向PD和TiKV写入大量元数据信息，比如表结构、索引定义、数据类型。而TiDB的SQL解析器依赖于内存中的Schema缓存来快速判断字段类型。type 128错误应该是导入的数据中包含不被TiDB支持的MySQL数据类型，导致TiDB在解析阶段尝试加载这些非法类型。建议先停掉导入任务，然后重启tidb实例重新查询试试，最后再次导入时将过时的或者不支持的数据类型替换成新的数据类型

Mingdr · 2026 年2 月 9 日 03:30

没导入之前整个测试都是正常的，导入后测试就反馈很多业务用不了了

Mingdr · 2026 年2 月 9 日 03:30

并没有，都是常见的字段类型

Mingdr · 2026 年2 月 9 日 03:33

导入已经完成了，重启还是没法查看这些表

Kongdom · 2026 年2 月 9 日 03:49

可以发一下脱敏表结构吗？感觉应该没影响才对。

Mingdr · 2026 年2 月 9 日 03:52

CREATE TABLE d_permission (
permission_id varchar(20) COLLATE utf8mb4_0900_ai_ci NOT NULL COMMENT ’ ',
title varchar(45) COLLATE utf8mb4_0900_ai_ci NOT NULL COMMENT ’ ',
parent_id varchar(20) COLLATE utf8mb4_0900_ai_ci DEFAULT NULL COMMENT ’ ',
uri varchar(100) COLLATE utf8mb4_0900_ai_ci DEFAULT NULL COMMENT ’ ',
type char(1) COLLATE utf8mb4_0900_ai_ci DEFAULT NULL COMMENT ’ ',
item_code varchar(20) COLLATE utf8mb4_0900_ai_ci DEFAULT NULL COMMENT ’ ',
icon varchar(50) COLLATE utf8mb4_0900_ai_ci DEFAULT NULL COMMENT ’ ',
icon_checked varchar(50) COLLATE utf8mb4_0900_ai_ci DEFAULT NULL COMMENT ’ ',
role_types json DEFAULT NULL COMMENT ’ ',
includes json DEFAULT NULL COMMENT ’ ',
priority int DEFAULT NULL COMMENT ’ ',
config json DEFAULT NULL COMMENT ’ ',
create_time datetime DEFAULT NULL COMMENT ’ ',
old_id int DEFAULT NULL COMMENT ’ ‘,
PRIMARY KEY (permission_id) /*T![clustered_index] CLUSTERED */
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT=’ ’

奇怪的是另外一个库也有这张表，访问就没问题，不过可能是数据有差别，但是最开始这表的数据都是能正常访问的，导入之后才报错的

独善其身 · 2026 年2 月 9 日 04:19

不支持的数据类型,得看看类型转换看看

TiDBer_SSUU · 2026 年2 月 9 日 06:19

是不是有导错过库，IP、端口、库名写错之类的

Mingdr · 2026 年2 月 9 日 06:33

唯一写错过的是导入的yml配置中status-port = 30004 ，然后改了重新导入。ip和库名我检查过，没有问题

TiDBer_ClS0jENG · 2026 年2 月 9 日 07:57

tidb-lightning 导入操作破坏了其他库的表结构

Mingdr · 2026 年2 月 9 日 08:18

应该是的，现在不知道怎么恢复了，只能删表

随缘天空 · 2026 年2 月 9 日 08:26

检查一下无法查看的表的元数据信息，看看元数据和实际的表结构有没有差别

TiDBer_Ejh0eCXc · 2026 年2 月 9 日 15:12

是全量导入吗?