PLEASE use SHOW CREATE TABLE; DESCRIBE is not descriptive enough.
You seem to be working with IPv4 IP addresses. IPv6 is upon us!
Your query inherently must do a full table scan in order to get the "total" upon which you do the ORDER BY. Since there are a million rows, it will take time.
count('*')
The quotes are not needed.
The two SELECTs are likely to be identical; order across JOIN does not matter. It does matter across LEFT JOIN. (INNER and OUTER add nothing.)
Suggestion...
First, see if this gives the correct information (albeit incomplet info):
SELECT e.sid, e.cid, COUNT(*) AS total
FROM event AS e
JOIN iphdr as h ON e.sid = h.sid
AND e.cid = h.cid
WHERE e.is_deleted = 0
GROUP BY i.ip_src, i.ip_dst
ORDER BY total DESC
LIMIT 5;
If so, then use that as a subquery, a la FROM (that-select) and LEFT JOIN to the other two tables to get the rest of the info.
The trick... The subquery is doing less work since it is touching 2 tables (vs 4). The LEFT JOINs only have to do 5 probes each, not a million.
You don't need all the derived tables. You are joining the basic (product
) too many times. You can write the query joining it only once.
Compound indices are a must for EAV designs. Try adding an index on (attribute_id, product_id, value)
and then the query:
SELECT t0.id,
t1.`value` AS length,
t2.`value` AS height,
t3.`value` AS family
FROM
products t0
INNER JOIN
product_eav_decimal t1
ON t1.product_id = t0.id
AND t1.attribute_id = 91
AND t1.`value` BETWEEN 15 AND 35
LEFT JOIN
product_eav_decimal t2
ON t2.product_id = t0.id
AND t2.attribute_id = 80
--
--
--
LEFT JOIN -- LEFT or INNER join
product_eav_decimal t6
ON t6.product_id = t0.id
-- AND t6.attribute_id =
ORDER BY t0.id ASC ;
Best Answer
I'm not certain I understand your requirements for this, however the following will return a row for each row in Table1.
Assuming [accountID] is an integer, you'd need to:
You should always specify the schema (I used
dbo
since it is the default). I've also added anORDER BY
clause to make the output easier to understand.It might make more sense to extend this to creation of the actual key field, as such:
If the table
dbo.Table
already has a clustered primary key, you'd either not makeLookup
a primary key, or perhaps you'd drop the existing primary key, and makeLookup
the new primary key.