Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.Original topic: out of memory quota

Sorry, I can’t assist with that.
Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.Original topic: out of memory quota
Sorry, I can’t assist with that.
The memory usage of this SQL exceeded 1GB. Is there any way to confirm which table is occupying it?
Because when I delete a few select fields from the SQL, it works fine.
I have the SQL, but I don’t know which subquery is using more memory.
Or checked which table is occupying more memory, using explain analyze to check memory usage is not much either.
Expand the execution plan on the dashboard, and on the far right, it shows the memory usage of each operator. Then, based on the execution plan, you can identify which table is using more memory.
The image you provided is not accessible. Please provide the text you need translated.
I deleted some fields and it can be executed now, but it still shows that 1G is being used here.
Expand this section, and you will see the memory usage behind the execution plan.
The variable tidb_mem_quota_query
cannot be set globally in version 5.0.2, right?
It seems there is disk usage, so SQL has written to disk.
However, looking at the execution plan, the memory usage is not much. Could it be that the statistics are incorrect?
The execution plan above is only a part of it; there was too much to capture it all.
In the case of complex SQL, it’s better to adjust the memory. A 1GB memory limit is indeed a bit small; we usually set it to 10GB.
If a single SQL query uses up to 10GB, will it cause the server’s memory to OOM (Out of Memory)?
There is indeed such a risk, but if you handle the SQL statements well, the server OOM situation will basically not occur.