2

I'm trying to use a subquery to speed up a query on a very large table right now 30 million row it most likely going to end up close to 1 billion rows.

My table lnmntr is as follow

  • Lnmntr_ndx: auto increment index,
  • Val: Numeric,
  • T_stamp: Time_Stamp indexed,
  • Row_id: Numeric

So my main query looks like this. This basically execute in no time. It select the 500 row following an autoincrement index

SELECT * 
FROM CLD_DB.lnmntr 
WHERE lnmntr_ndx >= 18411001 
ORDER BY lnmntr_ndx ASC 
LIMIT 500;

My subquery is used to find 1 row with the correct val. I've added a between timestamp here because I know around what time I'll find the row I need and since it's indexed it speed up thing. This query executes in about .4 seconds

SELECT Lnmntr_ndx 
FROM CLD_DB.lnmntr 
WHERE (t_Stamp BETWEEN '2016-06-05 16:22:04' AND '2016-06-05 16:23:04') 
  AND (Row_id IN (0,500,1000,1500,2000,2500,3000,3500,4000,4500,5000,
                  5500,6000,6500,7000,7500,8000,8500,9000,9500) 
  AND Val = 49092400); 

but when I bunch the 2 queries together, I end up with a 20 second query

SELECT * 
FROM CLD_DB.lnmntr 
WHERE lnmntr_ndx >= (SELECT Lnmntr_ndx 
                     FROM CLD_DB.lnmntr
                     WHERE (t_Stamp BETWEEN '2016-06-05 16:22:04' AND '2016-06-05 16:23:04') 
                       AND (Row_id IN (0,500,1000,1500,2000,2500,3000,3500,4000,4500,5000,
                        5500,6000,6500,7000,7500,8000,8500,9000,9500) 
                       AND Val = 49092400)
                     )
ORDER BY lnmntr_ndx ASC 
LIMIT 500;

I could run the 2 queries back to back to speed up thing but it would be much easier to run a single query. And id really like to know why they get this slow when bunched together

  • 2
    To understand performance issues the first thing to do is compare the various query plans: mariadb.com/kb/en/mariadb/explain – Nick.McDermaid Jun 5 '16 at 23:54
  • Use EXPLAIN PLAN and post up the result. There will be more eye to check what's wrong with your query. A Sub-select are totally different than a SELECT JOIN. – mootmoot Jun 6 '16 at 16:54
1

I'm not an expert on mysql/mariadb, but I suspect that it is running the sub-query one for every row in CLD_DB.lnmntr, or at least every row it needs to until it finds 500 that match the condition (which might just be 500 or might be far more depending on your data). Some SQL engines are bright enough to see that the inner query is invariant within the context of the current statement and only run it once, but IIRC mariadb's query planner doesn't do that sort of thing.

Assuming you have an index on CLD_DB.lnmntr your first query will result in a seek to the first point where lnmntr_ndx >= 18411001 then an ordered partial scan until 500 rows are found (or it hits the end). Even if the inner query were pretty much instantaneous so there would be very little difference between running it once and running it some hundreds or thousands of times, if it needs to be run for each row then you are forcing it to scan down the index from the beginning until 500 rows after the point where lnmntr_ndx is greater than the value.

So it could be either or both of these factors. To confirm which use EXPLAIN to look at the query plan, as suggested by Nick, and edit your question to add the resulting information. It would also be useful to provide the relevant table definitions (columns and their types, and the indexes & keys).

  • SHOW CREATE TABLE My_Table\G; - the result from this can be copied and pasted into other tools! – Vérace Jun 6 '16 at 16:23
0

A likely reason is that the subquery cant't be optimized using materialization. We have run into this a few times, and usually use temporary MEMORY tables as a workaround.

0

What's to keep that subquery from returning 0 rows or more than 1 row? Doesn't it need ORDER BY ... LIMIT 1?

Use JOIN, not a subquery like you are doing. That should help performance.

Temp tables are MEMORY by default. Don't try to force it; the query could crash because of max_heap_table_size.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy