I am supposed to write a query which requires joining 3 tables.
The query designed by me works fine, but it takes a lot of time to execute.
SELECT v.LinkID, r.SourcePort, r.DestPort, r.NoOfBytes, r.StartTime , r.EndTime, r.Direction, r.nFlows
FROM LINK_TBL v
INNER JOIN NODEIF_TBL n
INNER JOIN RAW_TBL r ON
r.RouterIP=n.ifipaddress
and n.NodeNumber=v.orinodenumber
and v.oriIfIndex=r.OriIfIndex;
Is there any issue w.r.t performance in this query ?
Try this one put the on conditions in the joins
SELECT v.LinkID, r.SourcePort, r.DestPort, r.NoOfBytes, r.StartTime , r.EndTime, r.Direction, r.nFlows
FROM LINK_TBL v
INNER JOIN NODEIF_TBL n ON (n.NodeNumber=v.orinodenumber )
INNER JOIN RAW_TBL r ON (r.RouterIP=n.ifipaddress and v.oriIfIndex=r.OriIfIndex)
Try this:
SELECT v.LinkID, r.SourcePort, r.DestPort, r.NoOfBytes, r.StartTime , r.EndTime, r.Direction, r.nFlows
FROM LINK_TBL v
INNER JOIN NODEIF_TBL n ON
n.NodeNumber=v.orinodenumber
INNER JOIN RAW_TBL r ON
r.RouterIP=n.ifipaddress
and v.oriIfIndex=r.OriIfIndex;
The join order is somewhat weird. I don't work with mysql so maybe it is just some unique way to join, but usually you join like:
FROM
a
INNER JOIN b ON a.id1 = b.id2
INNER JOIN c ON b.id3 = c.id4
Since you are using INNER JOIN this way you first filter out a with b joins and only then use the remaining join to filter out thus saving a lot of comparison actions. Imagine each table has 1 thousand rows. When you add c this becomes 1 million comparisons. Meanwhile with my example it would only be 1000 + 1000 comparisons instead of 1000 * 1000.
Related
So I was working on the problem of optimizing the following query I have already optimized this to the fullest from my side can this be further optimized?
select distinct name ad_type
from dim_ad_type x where exists ( select 1
from sum_adserver_dimensions sum
left join dim_ad_tag_map on dim_ad_tag_map.id=sum.ad_tag_map_id and dim_ad_tag_map.client_id=sum.client_id
left join dim_site on dim_site.id = dim_ad_tag_map.site_id
left join dim_geo on dim_geo.id = sum.geo_id
left join dim_region on dim_region.id=dim_geo.region_id
left join dim_device_category on dim_device_category.id=sum.device_category_id
left join dim_ad_unit on dim_ad_unit.id=dim_ad_tag_map.ad_unit_id
left join dim_monetization_channel on dim_monetization_channel.id=dim_ad_tag_map.monetization_channel_id
left join dim_os on dim_os.id = sum.os_id
left join dim_ad_type on dim_ad_type.id = dim_ad_tag_map.ad_type_id
left join dim_integration_type on dim_integration_type.id = dim_ad_tag_map.integration_type_id
where sum.client_id = 50
and dim_ad_type.id=x.id
)
order by 1
Your query although joined ok, is an overall bloat. You are using the dim_ad_type table on the outside, just to make sure it exists on the inside as well. You have all those left-joins that have NO bearing on the final outcome, why are they even there. I would simplify by reversing the logic. By tracing your INNER query for the same dim_ad_type table, I find the following is the direct line. sum -> dim_ad_tag_map -> dim_ad_type. Just run that.
select distinct
dat.name Ad_Type
from
sum_adserver_dimensions sum
join dim_ad_tag_map tm
on sum.ad_tag_map_id = tm.id
and sum.client_id = tm.client_id
join dim_ad_type dat
on tm.ad_type_id = dat.id
where
sum.client_id = 50
order by
1
Your query was running ALL dim_ad_types, then finding all the sums just to find those that matched. Run it direct starting with the one client, then direct with JOINs.
At work I came across this sort of query:
select distinct psv.pack_id from pack_store_variant psv, pack p
where p.id = psv.pack_id and p.store_id = 1 and psv.store_variant_id = 196;
Being new to the select from table1, table2 I did a bit of searching and found out this does basically a cartesian product of the two tables. I thought that this is unnecessarily creating NxM rows, we can just use a regular join and it should work. So I wrote this query:
SELECT DISTINCT pack_id from (SELECT pack_id, store_id, store_variant_id
FROM pack JOIN pack_store_variant ON pack.id = pack_store_variant.pack_id) as comb
where comb.store_id = 1 AND comb.store_variant_id = 196;
Surprisingly when I did the comparison, the first one was an order of magnitude faster than mine. Does my query suck somehow? Or am I not understanding the difference between cross join/inner join properly?
Your query is not so good. You split your query into two selects. The inner one creates a table, on which you then select again. That's not very efficient. This is how I would do it.
select distinct psv.pack_id from pack_store_variant as psv
Join pack as p on p.id = psv.pack_id
where p.store_id = 1 and psv.store_variant_id = 196;
My query is running too slow.....
any ways to speed it up?
SELECT SQL_CALC_FOUND_ROWS a.*, b.*, c.*, d.*, e.*, f1.*, st6.*
FROM tbl_a a
LEFT JOIN tbl_b b ON a.m_id = b.m_id
LEFT JOIN tbl_c c ON a.ms_id = c.ms_id
LEFT JOIN tbl_d d ON a.gd_id = d.gd_id
LEFT JOIN tbl_e e ON a.sd_id = e.sd_id
LEFT JOIN tbl_f f1 ON a.tp_id = f1.tp_id
LEFT JOIN
(
SELECT g.*, GROUP_CONCAT(f2.tp_name SEPARATOR ',') tp_name, f2.tp AS tp
FROM tbl_g g
LEFT JOIN tbl_f f2 ON g.tp_id = f2.tp_id
GROUP BY s_id
)st6 ON st6.s_id = a.s_id
Do not use LEFT unless you have a specific reason for it. I see no hint of such here.
A query like this is best optimized if it can perform the subquery first. However, 'LEFT' is a hint that it cannot be. Remove all the LEFTs and see if it is fast enough and gives the "right" answer.
Check to see that there is a PRIMARY KEY or INDEX on gd_id in both of the indicated tables in the following. (And do likewise for other JOINs.)
JOIN tbl_d d ON a.gd_id = d.gd_id
If you still need help, provide SHOW CREATE TABLE for each table. And EXPLAIN SELECT ...;.
I have this query:
SELECT hit.timestamp,hit.id,config.Name,hit.meter_id,levels.LevelName, pos.sm_pos , hit.hit_value
FROM pos,hit,controllers,levels,config
WHERE hit.id=config.id
AND hit.meter_id=levels.id
AND pos.id=hit.id
AND pos.controller_id=controllers.id;
How to make an inner join query from this? With aliases or something? I was looking and I can't find anything for multiple table query.
The way you are joining tables is outdated now. It was used eartlier, now we use keyword like INNER/NATURAL/LEFT OUTER/RIGHT OUTER/CROSS etc. to join tables on basis of requirement.
Refer Join in Mysql
SELECT hit.timestamp,
hit.id,
config.Name,
hit.meter_id,
levels.LevelName,
pos.sm_pos,
hit.hit_value
FROM hit
INNER JOIN config
ON hit.id = config.id
INNER JOIN levels
ON hit.meter_id = levels.id
INNER JOIN POS
ON pos.id = hit.id
INNER JOIN controllers
ON pos.controller_id = controllers.id;
Note : The query posted by you is according the SQL-89 standard and the second posted by me is according to SQL-92.
The SQL-92 standard introduced INNER JOIN .. ON and OUTER JOIN .. ON in order to replace the more complex(?) syntax of SQL-89.
If you want to reformat your query, you can do it like this:
SELECT
H.timestamp,
H.id,
F.Name,
H.meter_id,
L.LevelName,
P.sm_pos,
H.hit_value
FROM pos AS P
INNER JOIN controllers AS C ON P.controller_id = C.id
INNER JOIN hit AS H ON P.id = H.id
INNER JOIN levels AS L ON H.meter_id = L.id
INNER JOIN config AS F ON H.id =F.id;
Notice that I've taken the liberty to add aliases on your table names, this can simplify your queries alot.
To understand how joins work in MySQL, read about it here in the manual. A good tutorial about joins was written by Jeff Atwood, you can find it here.
As part of the process of replacing some old code that used an incredibly slow nested select, I've ended up with a query that looks like this:
SELECT r3.r_id AS r3_id, r2.r_id AS r2_id, r1.r_id AS r1_id
FROM
table_r r3
LEFT JOIN (
table_r r2
INNER JOIN (
table_r r1
INNER JOIN table_d d ON r1.r_id = d.r_id
) ON r2.r_id = r1.parent_id
) ON r3.r_id = r2.r_id
WHERE d.d_id = 3
So in the innermost join, I'm looking for the records in table_r (copy r1) which have a relationship with a subset of records from table_d.
In the next join out, I'm looking for records in a second copy of table_r (r2) whose main index (r_id) matches the parent index (parent_id) of the records from the previous join.
Then I'm trying to do a LEFT JOIN with a third copy of table_r (r3), simply matching r_id with the r_id of the previous join. The idea of this outermost join is to get ALL of the records from table_r, but to then do the equivalent of a NOT IN select by using a further condition (not yet in my query) to determine which records in r3 have NULLs for r2_id.
The problem is that the LEFT JOIN is not giving me the whole of table_r. It's giving me the same subset of records that I get without the final join - in other words, the same thing as an INNER JOIN. So whereas I'm expecting 1208 records, I get 508.
I know I must be doing something screwy here...
What happens, if you try this?
SELECT r3.r_id AS r3_id, r2.r_id AS r2_id, r1.r_id AS r1_id
FROM
table_r r3
LEFT JOIN (
table_r r2
INNER JOIN (
table_r r1
INNER JOIN table_d d ON r1.r_id = d.r_id AND d.d_id = 3
) ON r2.r_id = r1.parent_id
) ON r3.r_id = r2.r_id
What I did was moved the d.d_id = 3 from where clause to the INNER JOINs ON qualifiers.