【 TiDB 使用环境】生产环境 /测试
【 TiDB 版本】7.1.2
【复现路径】
- 创建一个包含 virtual 生成列的表
- 设置tiflash副本数为1
- 插入几条数据
- 设置使用执行引擎。set tidb_isolation_read_engines = ‘tikv,tiflash’;
- 执行带排序的 select 查询，查询结果中包含前面创建的生成列（使用 * 或显示指定生成列的名称都一样）, 查询语句中包含order by 子句 和 limit子句，没有offset或者offset值为0
【遇到的问题：问题现象及影响】
按以上复现路径执行完后，服务端返回类似下面的错误信息
Error Code: 1105
Not found column table_scan_1 in block. There are only columns: table_scan_0, table_scan_2
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
附上创建表的语句和执行的sql
– 创建表
CREATE TABLE generate_demo (
id BIGINT(20) NOT NULL,
created_at DATETIME NOT NULL,
is_removed TINYINT(1) NOT NULL,
updated_at DATETIME DEFAULT NULL,
__since_at DATETIME GENERATED ALWAYS AS (updated_at) VIRTUAL,
PRIMARY KEY (id)
);
– 设置tiflash副本
ALTER TABLE test.generate_demo SET tiflash replica 1;
– 初始化数据
INSERT INTO generate_demo
(id, created_at, is_removed, updated_at)
VALUES (1, NOW(), 0, NULL),
(2, NOW(), 1, NOW())
;
– 查询
SELECT *
FROM generate_demo
ORDER BY created_at ASC
LIMIT 100;
【备注】
我本地开发环境还有一个 tidb 6.1的版本，同样的执行方式就能正常返回结果
另外补充几个在7.1版里能正常返回结果的现象：
- select 语句中只包含order by或者只包含limit 两者之一都能正常返回结果。
- order by 和 offset子句都同时存在，且offset 设置为大于0的值也能正常返回
- 再次试验的结果证实了只有 virtual 方式的生成列才会出问题，stored 的生成列不会出错。但是修给一个表新增列的时候只支持 virtual 的生成列
继续验证后补充信息：
- 查看了执行计划后发现出错的时候实际使用的是batchCop方式，并不是mpp方式，这个是之前没有发现的。启用 tidb_enforce_mpp 后之前一直以为默认会使用mpp方式，结果证明并不一定是，还得得看执行计划才能确认。执行explain + 前面出错的查询语句输出信息如下
执行explain analyze + 前面出错的查询语句，报的错误跟直接执行前面出错的查询语句报的错误一样 - 当tidb_isolation_read_engines 设置为‘tiflash’时，执行方式改为 cop 方式
在此模式下sql是能正常执行的
