Execution Plan Analysis

Translated
1

Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.

Original topic: 执行计划分析

| username: Running

Can someone analyze this SQL for me? Is there any room for optimization?

2
| username: weixiaobing | Original post link

The statistics for table b are inaccurate. It is recommended to recollect them. Additionally, you can run an EXPLAIN ANALYZE to check. If it is a production environment, evaluate the impact of execution.

3
| username: tidb菜鸟一只 | Original post link

Is table B large? If it is, directly using a hint will bypass the index on table A.

4
| username: Kongdom | Original post link

As soon as you see stats:pseudo, you can directly perform table statistics collection.
analyze table net_nasipschoollocate

If you only need to retrieve ‘a’ from the result set, you can try using exists.

5
| username: ddhe9527 | Original post link

Try creating a composite index on table a with (schoolcode, tick_useripint).

6
| username: Running | Original post link

Where can it be analyzed that the statistics of table B are inaccurate?

7
| username: Running | Original post link

I want to know how that 18094649 came about.

8
| username: Kongdom | Original post link

Estimated number of result rows

9
| username: tidb菜鸟一只 | Original post link

Seeing stats:pseudo generally indicates that the statistics are not very accurate, which is a hint given by TiDB.

10
| username: tidb菜鸟一只 | Original post link

Aren’t you a hash join? It’s approximately equal to the product of the number of rows in your two result sets, 3024840.37 * 5.98.

11
| username: system | Original post link

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.