Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.
Original topic: 同一个sql指纹， 产生了不同的执行计划id，但计划内容又一样！为什么？
[TiDB Usage Environment] Production Environment
[TiDB Version]
[Reproduction Path] TiDB Dashboard → SQL Statement Analysis, sorted by execution plan count
[Issue] Found multiple different execution plans under the same SQL fingerprint. Upon checking the detailed plan information, the execution plans appear identical (using the same index and operator). So why are different execution plans still being generated?
Even for Prepare statements, the execution plan cache must be enabled to skip the generation of the execution plan. There are also a bunch of situations that will cause the execution plan cache to become invalid. You can read it yourself.
The LRU list is designed as a session-level cache because Prepare /Execute cannot be executed across sessions.
Moreover, the current execution plan cache of TiDB is session-level, so even if two sessions execute the same SQL using Prepare statements with the cache enabled, there will still be two plans.
As for the execution plan cache of non-Prepare statements,
it is disabled by default. So if you are not even executing through Prepare statements, by default, there will be different execution plans.
“Even for Prepare statements, the execution plan cache must be enabled to skip the generation of the execution plan.”
Does generating an execution plan always result in a new execution plan ID?
The ID should uniquely identify an instance. Even if the content is the same, the IDs should be different if they are generated repeatedly. After all, no matter how small the execution plan is, it still occupies memory.
What is the reason? Waiting for the result.
Isn’t this somewhat similar to Oracle? I’m not quite sure, let’s wait for an expert to answer.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
|
username: 帅的掉渣
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: