Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.
Original topic: select执行计划中的tabledual
[TiDB Usage Environment] Production Environment / Testing / PoC
[TiDB Version]
[Reproduction Path] What operations were performed when the issue occurred
[Encountered Issue: Problem Phenomenon and Impact]
Under what circumstances does tabledual occur, and there is another execution plan for the same batch of SQL.
The execution plan with tabledual has very low latency.
[Resource Configuration]
[Attachments: Screenshots/Logs/Monitoring]
Is there a limit in SQL?
Limit 0 will be directly optimized to table_dual to avoid constructing useless execution plans.
Is there caching? The first read is empty, and the second read goes through table_dual.
The two values of customerno>?<? in the condition will change, and the values queried each time will not be the same.
Is it possible for a situation like a.customerno >= 2 and a.customerno < 1 to occur? In this case, the query result would be limit 0, and the SQL execution plan would be directly optimized to table_dual to avoid constructing a useless execution plan.
Then it should be the situation mentioned by the previous poster. TiDB is still very smart~ 
It feels like this. Change to a condition that cannot possibly have data and check the execution plan to confirm.
Manually gave a false condition, it indeed resulted in a tabledual.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
|
username: chenhanneu
|
username: 
|
username: 
|
username: 
|
username: