tidb delete加条件删数据失败

🪐 TiDB 技术问题 部署&运维管理
21

@xie123 楼主什么进度了？我特意点了关注，就是想知道是什么情况~

image

22

同等一个结果

23

我遇到过一次是coprocessor的cache的问题，关了cache后就可以了。不过我遇到问题是我自己编译的版本，如果这个不是你的生产集群，可以关了cache试一下。
https://docs.pingcap.com/zh/tidb/v5.4/tidb-configuration-file#capacity-mb

同样关注+1

24

好奇 好奇

25

会不会是MVCC机制的原因？

26

重建后还没试过。我后续新建其他表名测一下。之前表rename了，上面测试部署是rename后的表

27

SHOW INDEXES FROM table_name;
±----------------------------------±-----------±---------±-------------±------------±----------±------------±---------±-------±-----±-----------±--------±--------------±--------±-----------±----------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment | Visible | Expression | Clustered |
±----------------------------------±-----------±---------±-------------±------------±----------±------------±---------±-------±-----±-----------±--------±--------------±--------±-----------±----------+
| table_name | 1 | ds | 1 | ds | A | 0 | NULL | NULL | YES | BTREE | | | YES | NULL | NO |
±----------------------------------±-----------±---------±-------------±------------±----------±------------±---------±-------±-----±-----------±--------±--------------±--------±-----------±----------+

ADMIN CHECK INDEX table_name ds;
Query OK, 0 rows affected (0.05 sec)

28

没有动过

29

建表语句
CREATE TABLE table_name (
weeks varchar(25) COLLATE utf8_unicode_ci DEFAULT NULL,
type varchar(50) COLLATE utf8_unicode_ci DEFAULT NULL,
cnt_x bigint(11) DEFAULT ‘0’,
avg_x double(11,4) DEFAULT ‘0’,
xxx bigint(10) DEFAULT ‘0’,
ds date DEFAULT NULL,
KEY ds (ds)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci

30

select * from INFORMATION_SCHEMA.CLUSTER_TIDB_TRX;
±------------------±-------------------±---------------------------±-------------------±------------------------±------±-------------------±----------------±-----------------±-----------±-----±--------------±---------------------------------------------------------------------+
| INSTANCE | ID | START_TIME | CURRENT_SQL_DIGEST | CURRENT_SQL_DIGEST_TEXT | STATE | WAITING_START_TIME | MEM_BUFFER_KEYS | MEM_BUFFER_BYTES | SESSION_ID | USER | DB | ALL_SQL_DIGESTS |
±------------------±-------------------±---------------------------±-------------------±------------------------±------±-------------------±----------------±-----------------±-----------±-----±--------------±---------------------------------------------------------------------+
| xx:10080 | 447374316973326405 | 2024-01-30 14:53:03.669000 | NULL | NULL | Idle | NULL | 0 | 0 | 63440587 | root | db_name | [“a200e35b257452d27bbad7f5cb67435a0f5804848baafbc6674212c917816245”] |
±------------------±-------------------±---------------------------±-------------------±------------------------±------±-------------------±----------------±-----------------±-----------±-----±--------------±---------------------------------------------------------------------+

31

最后面回复贴了

32

能不能在一个会话里面操作，然后截个图出来

begin
select * from table_name where 条件字段2=xxx and 条件字段1 =‘xx’ ;
delete from table_name where 条件字段2=xxx and 条件字段1 =‘xx’ ;
33

看了一下各位大佬回复，这边问了一下业务人员，整理了一下所有操作流程。重建索引删除也无效

问题复现步骤：
1、hive2mysql任务（sqoop）
任务导入前提，delete from table_name where ds=‘导入日期’
2、发现任务有问题，标记任务失败，实际application任务还在写入…
3、还行写入的时候，手动删除导入当天数据 delete from table_name where ds=‘2024-01-11’
4、select * from table_name where ds=‘2024-01-11’ 查询不到数据，实际当天还有数据
5、更换ds='2024-01-11’当天其他条件查询，有数据
6、其他条件无法删除ds='2024-01-11’当天数据。不加条件也不能删除

rename表问题排查
mysql> select * from table_name limit 1;
±----------------------±-----------±-----------±------------±--------±-----------+
| weeks | xxxxxxxxxx | xxxxxxxxxx | xxxxxxxxxxx | xxx | ds |
±----------------------±-----------±-----------±------------±--------±-----------+
| 2024-01-05~2024-01-11 | xxxx | x | xxxxxx.8571 | xxxxxxx | 2024-01-11 |
±----------------------±-----------±-----------±------------±--------±-----------+
1 row in set (0.00 sec)

mysql> select * from table_name where ds=‘2024-01-11’ limit 1;
Empty set (0.00 sec)

mysql> EXPLAIN SELECT * FROM table_name;
±----------------------±--------±-------------±----------------------------------------±---------------------+
| id | estRows | task | access object | operator info |
±----------------------±--------±-------------±----------------------------------------±---------------------+
| TableReader_7 | 141.00 | root | | data:TableFullScan_6 |
| └─TableFullScan_6 | 141.00 | cop[tiflash] | table:table_name | keep order:false |
±----------------------±--------±-------------±----------------------------------------±---------------------+
2 rows in set (0.02 sec)

mysql> EXPLAIN SELECT * FROM table_name where ds=‘2024-01-11’ limit 1;
±-------------------------------±--------±----------±------------------------------------------------------±------------------------------------------------+
| id | estRows | task | access object | operator info |
±-------------------------------±--------±----------±------------------------------------------------------±------------------------------------------------+
| IndexLookUp_20 | 0.00 | root | | limit embedded(offset:0, count:1) |
| ├─Limit_19(Build) | 0.00 | cop[tikv] | | offset:0, count:1 |
| │ └─IndexRangeScan_17 | 0.00 | cop[tikv] | table:table_name, index:ds(ds) | range:[2024-01-11,2024-01-11], keep order:false |
| └─TableRowIDScan_18(Probe) | 0.00 | cop[tikv] | table:table_name | keep order:false |
±-------------------------------±--------±----------±------------------------------------------------------±------------------------------------------------+
4 rows in set (0.00 sec)

重建索引删除无效

mysql> DROP INDEX ds ON table_name;
Query OK, 0 rows affected (0.57 sec)

mysql> DELETE from table_name where ds=‘2024-01-11’ limit 1;
Query OK, 0 rows affected (0.00 sec)

mysql> DELETE from table_name limit 1;
Query OK, 0 rows affected (0.00 sec)

mysql> CREATE INDEX ds ON table_name (ds);
Query OK, 0 rows affected (3.03 sec)

mysql> DELETE from table_name limit 1;
Query OK, 0 rows affected (0.01 sec)

mysql> DELETE from table_name where ds=‘2024-01-11’ limit 1;
Query OK, 0 rows affected (0.01 sec)

34

这个表有对应的tifliash副本？你把他的副本set成0之后试一下，是不是tiflash副本的问题

1 个赞
35

应该是tiflash副本问题了。查询不到数据了

mysql> select * from table_name where ds=‘2024-01-11’ limit 1;
Empty set (0.01 sec)

mysql> select * from table_name limit 1;
Empty set (0.01 sec)

select count() from table_name limit 1;
±---------+
| count() |
±---------+
| 0 |
±---------+
1 row in set (0.00 sec)

36

mysql> ALTER TABLE table_name SET TIFLASH REPLICA 0;
Query OK, 0 rows affected (1.82 sec)

mysql>
mysql> select * from table_name where ds=‘2024-01-11’ limit 1;
Empty set (0.01 sec)

mysql> select * from table_name limit 1;
Empty set (0.01 sec)

select count() from table_name limit 1;
±---------+
| count() |
±---------+
| 0 |
±---------+
1 row in set (0.00 sec)

37

现在tiflash日志找不到相关表记录了，之前看查询执行走tiflash大概搜了一下没明显报错。怎么避免出现同样问题？

38

:flushed:意思是rename之后，还能从rename之前的tiflash里读取数据？

39

你再把tiflash设置成1看看能恢复不能，你版本有点低，tiflash功能支撑的不是很好。。。。

40

admin check 下表看看，是不是索引数据不一致。