I've got a serious problem. Our Intranet is getting slower and slower. One of the mainreasons seems to be a slow mysql-query (it appears in the slow-query.log).
That query is asked every time an intranet-site is opened.
It looks like this:
SELECT w.Datetime, w.User_ID, w.Status, e.Lastname
FROM worktimes AS w
INNER JOIN employees AS e ON w.User_ID=e.ID
RIGHT JOIN (SELECT max(Datetime) AS Datetime, User_ID
FROM worktimes
WHERE Datetime>".$today." // variable of today 0.00 o'clock
AND Location='".$llocation['ID']."' // variable of one of 9 locations
GROUP BY User_ID) AS v
ON v.User_ID=w.User_ID AND w.Datetime=v.Datetime
ORDER BY e.Lastname;
The worktimes-table is somewhat greater with up to 200k rows (momentary 90k to testing reasons) and 13 columns. The whole query goes through a loop with 3 to 9 cycles.Has someone an idea how to make the queries faster?
edit: As wished here is the EXPLAIN-result.
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY <derived2> ALL NULL NULL NULL NULL 44006 Using temporary; Using filesort
1 PRIMARY w ALL NULL NULL NULL NULL 92378 Using where
1 PRIMARY e eq_ref PRIMARY,ID PRIMARY 4 ais_v1.w.User_ID 1 NULL
2 DERIVED worktimes ref Location Location 767 const 44006 Using index condition; Using where; Using temporary; Using filesort
The w table needs an index on INDEX(Location, Datetime). This should improve the performance.
you dont need to use worktimes twice
you can do it as follows:
SELECT max(w.Datetime) AS Datetime, w.User_ID, w.User_ID, w.Status, e.Lastname
FROM worktimes w left outer join employees e
on e.User_ID=w.User_ID
and w.Datetime>".$today." // variable of today 0.00 o'clock
AND w.Location='".$llocation['ID']."' // variable of one of 9 locations
GROUP BY w.User_ID
ORDER BY e.Lastname;
it will run faster than your existing query
Related
Two tables, first one is users and 2nd is posts, table posts structure is id,body,parent_id,user_id in this table all posts are inserted with parent_id is null, and if its a comment the parent_id is set to post id.
What I'm trying to do is join users table -to get user details- and get count of comments on each post.
I tried a couple of queries
select p.id,
users.id as 'from_id',
users.fullname as 'from_fullname',
users.role as 'from_role',
users.picture as 'from_picture',
p.body,
p.time_posted as 'time_posted',
p.attachment,
p.parent_id,
count(c.id) as counts
from
wall p
join
users on users.id = p.user_id
left join
wall c on c.parent_id = p.id
where
p.class_id = 8 and p.parent_id is null
group by
p.id
order by
`counts` ---->EXPLAIN RESULTS
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE p ref PRIMARY,parent_id,class_id,user_id parent_id 5 const 49920 Using index condition; Using where; Using temporary; Using filesort
1 SIMPLE users eq_ref PRIMARY PRIMARY 4 ischool.p.user_id 1 NULL
1 SIMPLE c ref parent_id parent_id 5 ischool.p.id 49920 Using index
This one takes average of around 2.7 sec to complete.
While my 2nd attempt
select p.id,
users.id as 'from_id',
users.fullname as 'from_fullname',
users.role as 'from_role',
users.picture as 'from_picture',
p.body,
(select count(*) from wall where parent_id= p.id ) as comments_count,
p.time_posted as 'time_posted',
p.attachment,
p.parent_id
from
wall p
left join
users on users.id = p.user_id
where
p.class_id = 8 and p.parent_id is NULL
order by
p.id DESC; --->Explain results
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY p ref parent_id,class_id parent_id 5 const 49920 Using where
1 PRIMARY users eq_ref PRIMARY PRIMARY 4 ischool.p.user_id 1 NULL
2 DEPENDENT SUBQUERY wall ref parent_id parent_id 5 ischool.p.id 49920 Using index
This query takes 1.4 sec to complete
given that im using MYSQL innodb with index on each and every id column.
so is there a better method to fetch posts and comment counts ?
why is subquery working nearly 2x faster than join ?
Basically Joins are more faster than sub query. Generally, new developer prefers to use sub-query.
The execution plan of query may impact on performance. Almost all cases queries joins are more faster than sub-query.
The basic difference is that sub-query execute query and load all data and based on those data execute another query.
and joins are all tables all loads with data so it performs fast execution of query.
In you query, if you want to show why you sub-query is faster than join use "explain " command to show how query is actually executed.
Following links may helpful to understand concepts:
http://www.chrislondon.co/joins-vs-subqueries/
http://www.sitepoint.com/using-explain-to-write-better-mysql-queries/
I have a fairly simple query which runs okay when I test it in phpMyAdmin:
SELECT
c.customers_id,
c.customers_cid,
c.customers_gender,
c.customers_firstname,
c.customers_lastname,
c.customers_email_address,
c.customers_telephone,
c.customers_date_added,
ab.entry_company,
ab.entry_street_address,
ab.entry_postcode,
ab.entry_city,
COUNT(o.customers_id) AS orders_number,
SUM(ot.value) AS totalvalue,
mb.bonus_points
FROM
orders AS o,
orders_total AS ot,
customers AS c,
address_book AS ab,
module_bonus AS mb
WHERE
c.customers_id = o.customers_id
AND c.customers_default_address_id = ab.address_book_id
AND c.customers_id = mb.customers_id
AND o.orders_id = ot.orders_id
AND ot.class = 'ot_subtotal'
** AND c.customers_gender = 'm' AND c.customers_lastname LIKE 'Famlex'
GROUP BY o.customers_id
The row marked with ** changes depending on filtering settings of the application making the query.
Now, when I test this in phpMyAdmin, the query takes a couple of seconds to run (which is fine, since there are thousands of entries and, as far as I know, when using COUNTs and SUMs indexes don't help) and the results are perfect, but when I run the exact same query in PHP (echoed before running), the MySQL thread loads a core to 100% and doesn't stop until I kill it.
If I strip the extra stuff to calculate the COUNT and SUM, the query finishes but the results are useless to me.
EXPLAIN:
1 SIMPLE mb ALL NULL NULL NULL NULL 48713 Using temporary; Using filesort
1 SIMPLE ot ALL idx_orders_total_orders_id NULL NULL NULL 811725 Using where
1 SIMPLE o eq_ref PRIMARY PRIMARY 4 db.ot.orders_id 1 Using where
1 SIMPLE c eq_ref PRIMARY PRIMARY 4 db.o.customers_id 1 Using where
1 SIMPLE ab eq_ref PRIMARY PRIMARY 4 db.c.customers_default_address_id 1
EXPLAIN after applying indexes and using joins:
1 SIMPLE c ref PRIMARY,search_str_idx search_str_idx 98 const 1 Using where; Using temporary; Using filesort
1 SIMPLE mb ALL NULL NULL NULL NULL 48713 Using where
1 SIMPLE ab eq_ref PRIMARY PRIMARY 4 db.c.customers_default_address_id 1
1 SIMPLE ot ref idx_orders_total_orders_id,class class 98 const 157004 Using where
1 SIMPLE o eq_ref PRIMARY PRIMARY 4 db.ot.orders_id 1 Using where
Use explicit join instead of implicit
SELECT
c.customers_id,
c.customers_cid,
c.customers_gender,
c.customers_firstname,
c.customers_lastname,
c.customers_email_address,
c.customers_telephone,
c.customers_date_added,
ab.entry_company,
ab.entry_street_address,
ab.entry_postcode,
ab.entry_city,
COUNT(o.customers_id) AS orders_number,
SUM(ot.value) AS totalvalue,
mb.bonus_points
FROM
orders o
join orders_total ot on o.orders_id = ot.orders_id
join customers c on c.customers_id = o.customers_id
join address_book ab on c.customers_default_address_id = ab.address_book_id
join module_bonus mb on c.customers_id = mb.customers_id
where
ot.class = 'ot_subtotal'
c.customers_gender = 'm'
AND c.customers_lastname = 'Famlex'
GROUP BY o.customers_id
Assuming all the joining keys are also primary key of those tables viz:
o.orders_id, c.customers_id, ab.address_book_id
You will need to add the following indexes if they are not added already
alter table orders add index customers_id_idx(customers_id);
alter table module_bonus add index customers_id_idx(customers_id);
alter table orders_total add index orders_id_idx(orders_id);
alter table orders_total add index orders_class_idx(class);
alter table customers add index search_str_idx(customers_gender,customers_lastname);
Make sure to take a backup of the tables before applying indexes.
Can you share SQL dump of your record so that I can take a look ?
phpMyAdmin automatically adds limit clause to the select queries, that is why I think you are getting the impression that in phpMyAdmin query is running fine but not via you PHP script.
Try to add explicit limit clause to the query say limit 0, 1000 in phpMyAdmin before running and see if that makes performance of phpMyAdmin slower.
so I have this query
SELECT a.`title`,a.`id`,a.`numvol`,a.`numepi`,a.`release_date`,
(SELECT COUNT(id) FROM `Release` r WHERE r.`article_id`=a.`id`) AS `num_rows`,
(SELECT COUNT(id) FROM `Article_views` av WHERE av.`article_id`=a.`id`) AS `num_rows2`
FROM `Article` a WHERE a.`type` = 'ani' ORDER BY a.`title` ASC
The first load takes up to 5 secs and if I do a refresh it will take about 0.001 sec, is there a way to uniform the loading time?
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY a ALL NULL NULL NULL NULL 567 Using where; Using filesort
3 DEPENDENT SUBQUERY av ALL NULL NULL NULL NULL 5301 Using where
2 DEPENDENT SUBQUERY r ALL NULL NULL NULL NULL 11717 Using where
I tried to do it with join but it didn't work at all so I gave up this way...
Solution
use barmar query. way better :) (and indexes -,-')
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY <derived2> ALL NULL NULL NULL NULL 536 Using temporary; Using filesort
1 PRIMARY a eq_ref PRIMARY PRIMARY 4 r.art.. 1 Using where
1 PRIMARY <derived3> ALL NULL NULL NULL NULL 574 Using where; Using join buffer
3 DERIVED Article_views index NULL article_id 4 NULL 5301 Using index
2 DERIVED Release index NULL article_id 4 NULL 11717 Using index
Thanks guys for your time and the solution :) I guess I need to redo a good part of this old project ahah :)
Try this query instead:
SELECT a.`title`,a.`id`,a.`numvol`,a.`numepi`,a.`release_date`, `num_rows`, `num_rows2`
FROM `Article` a
JOIN (SELECT article_id, COUNT(*) AS num_rows
FROM Release
GROUP BY article_id) r
ON r.article_id = a.id
JOIN (SELECT article_id, COUNT(*) AS num_rows2
FROM Article_views
GROUP BY article_id) av
ON av.article_id = a.id
WHERE a.`type` = 'ani'
ORDER BY a.`title` ASC
In my experience, JOINs are faster than correlated subqueries.
For performance, make sure you have indexes on Release.article_id and Article_views.article_id.
I guess, 2nd try is benefit from SQL QUERY CACHE. I wonder if adding SQL_NO_CACHE, every try took 5 secs?
SELECT SQL_NO_CACHE a.`title`,a.`id`,a.`numvol`,a.`numepi`,a.`release_date`,
....
INDEXES
Oops. you have no relevant INDEX. could you add following indexes?
ALTER TABLE Article ADD INDEX(type);
ALTER TABLE Release ADD INDEX(article_id);
ALTER TABLE Article_views ADD INDEX(article_id);
More Efficient Query
And your Query converted into JOIN. I guess this is much faster than yours. Assuming every Article has Release and Article_views
SELECT a.`title`,a.`id`,a.`numvol`,a.`numepi`,a.`release_date`,
COUNT(r.id) AS `num_rows`,
COUNT(av.id) AS `num_rows2`
FROM `Article` a JOIN Release r ON r.`article_id`=a.`id`
JOIN Article_views av ON av.`article_id`=a.`id`
WHERE a.`type` = 'ani'
GROUP BY a.title, a.id, a.numvol, a.numepi, a.release_date
ORDER BY a.`title` ASC;
That significant improvement on query latency is due to internal MySQL cache functioning.
After the first execution of the query the result set is cached in RAM, so the results second query which just matches the previous, are immediately taken from the RAM without HDD accesses.
There are different points of view about MySQL internal cache, and experts often recommend to disable it in highload production environments using memecached, Redis or some other caching layer instead.
But definitely you should try to optimize performance of your query with caching turned off - 5 seconds is extremely slow.
Try not to use subqueries, cause MySQL optimizer is not performant on them.
Store values of the counters (results of count()) in separate table and update them properly. Then you can use just the counters values in your query without performing heavy database request each time.
Create indexes, for example, for type field.
Use EXPLAIN for further optimizations
I'm having real problems with my Mysql statement, I need to join a few tables together, query them and order by the average of values from another table. This is what I have...
SELECT
ROUND(avg(re.rating), 1)AS avg_rating,
s.staff_id, s.full_name, s.mobile, s.telephone, s.email, s.drive
FROM staff s
INNER JOIN staff_homes sh
ON s.staff_id=sh.staff_id
INNER JOIN staff_positions sp
ON s.staff_id=sp.staff_id
INNER JOIN reliability re
ON s.staff_id=re.staff_id
INNER JOIN availability ua
ON s.staff_id=ua.staff_id
GROUP BY staff_id
ORDER BY avg_rating DESC
Now I believe this to work although I am getting this error "The SELECT would examine more than MAX_JOIN_SIZE rows; check your WHERE and use SET SQL_BIG_SELECTS=1 or SET SQL_MAX_JOIN_SIZE=# if the SELECT is okay".
I think this means that I have too many joins and because it is shared hosting it won't allow large queries to run I don't know.
What I would like to know is exactly what the error means (I have googled it but I don't understand the answers) and how I can work round it by maybe making my query more efficient?
Any help would be appreciated. Thanks
EDIT:
The reason I need the joins is so I can query the tables based on a search function like so...
SELECT
ROUND(avg(re.rating), 1)AS avg_rating
, s.staff_id, s.full_name, s.mobile, s.telephone, s.email, s.drive
FROM staff s
INNER JOIN staff_homes sh
ON s.staff_id=sh.staff_id
INNER JOIN staff_positions sp
ON s.staff_id=sp.staff_id
INNER JOIN reliability re
ON s.staff_id=re.staff_id
INNER JOIN availability ua
ON s.staff_id=ua.staff_id
WHERE s.full_name LIKE '%'
AND s.drive = '1'
AND sh.home_id = '3'
AND sh.can_work = '1'
AND sp.position_id = '3'
AND sp.can_work = '1'
GROUP BY staff_id
ORDER BY avg_rating DESC
EDIT 2
This was the result of my explain. Also I'm not great with MYSQL how would I set up foreign keys?
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE ua ALL NULL NULL NULL NULL 14 Using temporary; Using filesort
1 SIMPLE re ALL NULL NULL NULL NULL 50 Using where; Using join buffer
1 SIMPLE sp ALL NULL NULL NULL NULL 84 Using where; Using join buffer
1 SIMPLE sh ALL NULL NULL NULL NULL 126 Using where; Using join buffer
1 SIMPLE s eq_ref PRIMARY PRIMARY 4 web106-prestwick.ua.staff_id 1
EDIT 3: Thanks lc, it was my foreign keys, they were not set up correctly. Problem sorted
Maybe you should use more and/or better indexes on the tables.
According to the db you're using, the optimization may be faster or not with subqueries.
There may be 2 bottlenecks on your query:
try to remove the average function of your query. If your query speeds up, try to replace it with a subquery and see what happens.
The multiple joins often reduce performances, and there's nothing you can do except modifying your db schema. The simplest solution would be to have a table that precomputes data and reduces the work for your db engine. This table can be fulfilled with stored procedures triggered when you modify the data on the implied tables, or you can also modify the table values from your php application.
I'm not getting any errors as such just a minor performance issue.
EXPLAIN
SELECT
a.nid,
a.title,
a.uid,
b.parent,
b.weight,
c.name,
d.value
FROM table1 AS a INNER JOIN table2 AS b ON a.vid = b.vid AND a.status = 1
INNER JOIN table3 AS c ON c.uid = a.uid
INNER JOIN table4 AS d ON d.content_id = a.nid AND d.value_type = 'percent' AND d.function = 'average'
When I look at which tables are being referenced, everything is fine, but from table4 where it should only be selecting the "value" field, I'm getting an ALL being called...
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE a ref PRIMARY,vid,status,uid,node_status_type,nid status 4 const 1
1 SIMPLE b eq_ref PRIMARY PRIMARY 4 databasename.a.vid 1
1 SIMPLE c eq_ref PRIMARY PRIMARY 4 databasename.a.uid 1 Using where
1 SIMPLE d ALL NULL NULL NULL NULL 2 Using where
As you can see, it's selecting * from the final table (d). Why is it doing this when I only need ONE field selected from it? Can anyone help me out?
ALL means all rows, not all columns. Since it says there are no possible keys, I'd guess that you don't have an index on d.content_id or d.value_type or d.function.
If you wanted to be fancy, you could put an index across all 3 of those columns.
Are d.value_type and d.function indexed fields? That would be initial instinct as to the cause.
Add a multi-column index to table4 based on the content_type, value_type and function columns.
Your query isn't selecting all the columns from table4, it's selecting all the rows; this isn't much of a problem when there's only two.
Note that a MySQL query execution plan might not give the give the answer you expect when you're working with a small number of records; it can be faster for the database to do a full table scan in those circumstances.