[MDEV-26976] Optimization problem unless LIMIT is included (any LIMIT) Created: 2021-11-04 Updated: 2021-12-26 |
|
| Status: | Open |
| Project: | MariaDB Server |
| Component/s: | Server |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major |
| Reporter: | Nuno | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Attachments: |
|
| Description |
|
Hello, I wonder if this is a bug I found here... Say I have a `posts` table, and I want to query this `posts` table for the latest Posts by my Friends. Here's an "obvious" query (my User ID being 12345, and reducing the lookup by RID > 49251041):
This is taking 3.6s Looks "optimized" enough... Since I found this really strange, I tried an alternative:
This is also taking 3.6s The EXPLAIN looks pretty much the same, with a few more "rows" on the posts table. HOWEVER, by putting *any* LIMIT inside the subquery, no matter how big or small it is,
It straight away makes the query instant... In the EXPLAIN, I see an extra "step" that I'm not sure what it means: – Even if I have something like:
It's still taking its time... – In terms of amount of rows...
27754
649 In terms of indexes, posts: friends: Any ideas? Why do I need to put a LIMIT, and the basic STRAIGHT_JOIN isn't efficient by default? Note - this is on a much more complex query, but the above is a minimal example where the issue happens. – Using MariaDB 10.5.12 on CentOS 7 |
| Comments |
| Comment by Nuno [ 2021-11-05 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
After some investigation, I understand now it has to do with the "Derived Table Merge" ("derived_merge") option of the optimizer, and putting "LIMIT" stops the merge from happening. https://dev.mysql.com/doc/refman/5.7/en/derived-table-optimization.html However, I still don't understand why the first version of the query isn't efficient, despites the EXPLAIN saying it does use the indexes as expected. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Daniel Black [ 2021-12-01 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
So what does your new found tool of EXPLAIN FORMAT=JSON show? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Nuno [ 2021-12-26 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
danblack Very sorry for the delay. Great idea about trying `ANALYZE FORMAT=JSON` on this I see that in the inefficient queries there is an: "attached_condition": "friends.id2 = posts.`from`" But I don't understand why it's bad.. both those columns are BIGINT(18) UNSIGNED NOT NULL.
|