同样一个库，同样一个表，同样查询条件，结果不一样

[yulei7633]

SELECT string_131 FROM xxxxx WHERE form_id = 1734598 结果集是3条
SELECT count(*) FROMxxxxx WHERE form_id = 1734598 结果集是90条
string_131类型是：varchar(16383) COLLATE utf8mb4_general_ci DEFAULT NULL
请问一下，是不是因为大字段的原因？显示结果的条件不一样。

[templey]

看下执行计划

[forever]

把where条件的值用引号引起来

[wangcw]

COUNT DISTINCT下试试呢，或者COUNT( string_131 )

[Kongdom]

是不是启用TiFlash了？做一下表check看看。
https://docs.pingcap.com/zh/tidb/stable/sql-statement-admin-check-table-index#语法图

[成为一名优秀的DBA]

看执行计划

[yulei7633]

[zhaokede]

问题确实可能与 string_131 字段作为大字段（varchar(16383)）有关。数据库查询优化器可能会根据查询的不同（如是否涉及聚合函数）选择不同的执行计划。这可能导致在聚合查询（如 COUNT(*)）和非聚合查询（如 SELECT string_131）之间行为不同。

[yulei7633]

统一回复，原因是这个表是研发后来创建的，没有加入统计信息自动收集中，导致条件一样，结果集不一样的

[forever]

不同的执行计划理论上结果也不能不一样啊

[yulei7633]

这个我也是这样想的。但是重新收集这张表的执行计划后，查询结果就对了。具体原因还是不清楚。

[forever]

两个都用EXPLAIN ANALYZE 看下呢，看下真实的执行计划差异在哪里

[yulei7633]

上面的截图里面有

[yulei7633]

这个不能随便执行，占用资源太大了。

[有猫万事足]

是tiflash有bug吧。

正确的结果应该是几条？我猜这个90条才是正确结果。

估计收集统计信息后好了，是因为有统计信息了，就不走tiflash了。

[Kongdom]

那估计就是这个原因了

[yulei7633]

这个我没有执行。

[zhanggame1 (Ti D Ber G I13ecx U)]

不管执行计划有什么不同，同样的sql执行结果肯定是一样的，如果不一样就得检查索引是不是有问题了，用tiflash检查tiflash配置

[Kongdom]

这个语句只是检查是否一致，不会去处理差异。
如果不一致还是要执行analyze table重新收集。

[tidb菜鸟一只 (小菜一颗)]

重新收集统计信息之后，走的是tikv还是tiflash？