I have a query that takes 2minutes to count from table A and update Table B with the count result.
Everytime that a number in Table_B column Start matches the range in Table_A (readstart/readend) I should update read_count in Table_B.
id | readstart | readend | read_count
1 | 2999997 | 3000097 | 0
2 | 3000097 | 3000197 | 0
3 | 3000497 | 3000597 | 0
4 | 3001597 | 3001697 | 0
5 | 3001897 | 3001997 | 0
6 | 3005397 | 3005497 | 0
7 | 3005997 | 3006097 | 0
8 | 3006397 | 3006497 | 0
9 | 3006797 | 3006897 | 0
10| 3007497 | 3007597 | 0
Here is the table I should update with the count result :
CREATE TABLE `rdc_test` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`readstart` int(11) DEFAULT NULL,
`readend` int(11) DEFAULT NULL,
`read_count` int(11) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `readstart` (`readstart`),
KEY `readend` (`readend`)
) ENGINE=InnoDB AUTO_INCREMENT=11 DEFAULT CHARSET=utf8;
Here is the table from where I wanna count matching rows :
CREATE TABLE `1ips_chr1` (
`strand` char(1) DEFAULT NULL,
`chr` varchar(10) DEFAULT NULL,
`start` int(11) DEFAULT NULL,
`end` int(11) DEFAULT NULL,
`name` varchar(255) DEFAULT NULL,
`name2` varchar(255) DEFAULT NULL,
`id` int(11) NOT NULL AUTO_INCREMENT,
PRIMARY KEY (`id`),
KEY `start` (`start`),
KEY `end` (`end`)
) ENGINE=MyISAM AUTO_INCREMENT=34994289 DEFAULT CHARSET=latin1;
I did a test on 10 rows, the result was horrible..2 minutes to select count(*) and update 10 rows. I have about 350,000 rows in Table_A to update and 35,000,000 in table_B. I know that in average each count should return 30~40 as a result.
Here is my super slow query :
UPDATE rdc_test
SET rdc_test.read_count =
(
SELECT COUNT(start) as read_count
FROM 1ips_chr1
WHERE 1ips_chr1.start >= rdc_test.readstart
AND 1ips_chr1.start <= rdc_test.readend
)
Query OK, 10 rows affected (2 min 22.20 sec)
Rows matched: 10 Changed: 10 Warnings: 0
Try this :
UPDATE rdc_test t1
INNER JOIN
(
SELECT r.id AS id,
COUNT(l.start) AS read_count
FROM rdc_test r
LEFT OUTER JOIN start1ips_chr1 l
ON l.start >= r.readstart
AND l.start <= r.readend
GROUP BY r.id
) t2
ON t1.id = t2.id
SET t1.read_count = t2.read_count
Edit :
Due to the amount of datas you need to update, the best way is to recreate the table instead of perform an update :
CREATE TABLE new_rdc_test AS
SELECT r.id AS id,
r.readstart AS readstart,
r.readend AS readend,
COUNT(l.start) AS read_count
FROM rdc_test r
LEFT OUTER JOIN start1ips_chr1 l
ON l.start >= r.readstart
AND l.start <= r.readend
GROUP BY r.id, r.readstart, r.readend
Does this query run fast enough ?
Try to bring the COUNT(*) to application level (ie. store it as a variable in PHP/Java) then do the UPDATE, with that value. MySQL will not have to calculate that count for every record you update.
Related
I have a slow query, without the group by is fast (0.1-0.3 seconds), but with the (required) group by the duration is around 10-15s.
The query joins two tables, events (near 50 million rows) and events_locations (5 million rows).
Query:
SELECT `e`.`id` AS `event_id`,`e`.`time_stamp` AS `time_stamp`,`el`.`latitude` AS `latitude`,`el`.`longitude` AS `longitude`,
`el`.`time_span` AS `extra`,`e`.`entity_id` AS `asset_name`, `el`.`other_id` AS `geozone_id`,
`el`.`group_alias` AS `group_alias`,`e`.`event_type_id` AS `event_type_id`,
`e`.`entity_type_id`AS `entity_type_id`, el.some_id
FROM events e
INNER JOIN events_locations el ON el.event_id = e.id
WHERE 1=1
AND el.other_id = '1'
AND time_stamp >= '2018-01-01'
AND time_stamp <= '2019-06-02'
GROUP BY `e`.`event_type_id` , `el`.`some_id` , `el`.`group_alias`;
Table events:
CREATE TABLE `events` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`event_type_id` int(11) NOT NULL,
`entity_type_id` int(11) NOT NULL,
`entity_id` varchar(64) NOT NULL,
`alias` varchar(64) NOT NULL,
`time_stamp` datetime NOT NULL,
PRIMARY KEY (`id`),
KEY `entity_id` (`entity_id`),
KEY `event_type_idx` (`event_type_id`),
KEY `idx_events_time_stamp` (`time_stamp`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
Table events_locations
CREATE TABLE `events_locations` (
`event_id` bigint(20) NOT NULL,
`latitude` double NOT NULL,
`longitude` double NOT NULL,
`some_id` bigint(20) DEFAULT NULL,
`other_id` bigint(20) DEFAULT NULL,
`time_span` bigint(20) DEFAULT NULL,
`group_alias` varchar(64) NOT NULL,
KEY `some_id_idx` (`some_id`),
KEY `idx_events_group_alias` (`group_alias`),
KEY `idx_event_id` (`event_id`),
CONSTRAINT `fk_event_id` FOREIGN KEY (`event_id`) REFERENCES `events` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
The explain:
+----+-------------+-------+--------+---------------------------------+---------+---------+-------------------------------------------+----------+------------------------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+--------+---------------------------------+---------+---------+-------------------------------------------+----------+------------------------------------------------+
| 1 | SIMPLE | ea | ALL | 'idx_event_id' | NULL | NULL | NULL | 5152834 | 'Using where; Using temporary; Using filesort' |
| 1 | SIMPLE | e | eq_ref | 'PRIMARY,idx_events_time_stamp' | PRIMARY | '8' | 'name.ea.event_id' | 1 | |
+----+-------------+----------------+---------------------------------+---------+---------+-------------------------------------------+----------+------------------------------------------------+
2 rows in set (0.08 sec)
From the doc:
Temporary tables can be created under conditions such as these:
If there is an ORDER BY clause and a different GROUP BY clause, or if the ORDER BY or GROUP BY contains columns from tables other than the first table in the join queue, a temporary table is created.
DISTINCT combined with ORDER BY may require a temporary table.
If you use the SQL_SMALL_RESULT option, MySQL uses an in-memory temporary table, unless the query also contains elements (described later) that require on-disk storage.
I already tried:
Create an index by 'el.some_id , el.group_alias'
Decrease the varchar size to 20
Increase the size of sort_buffer_size and read_rnd_buffer_size;
Any suggestions for performance tuning would be much appreciated!
In your case events table has time_span as indexing property. So before joining both tables first select required records from events table for specific date range with required details. Then join the event_location by using table relation properties.
Check your MySql Explain keyword to check how does your approach your table records. It will tell you how much rows are scanned for before selecting required records.
Number of rows that are scanned also involve in query execution time. Use my below logic to reduce the number of rows that are scanned.
SELECT
`e`.`id` AS `event_id`,
`e`.`time_stamp` AS `time_stamp`,
`el`.`latitude` AS `latitude`,
`el`.`longitude` AS `longitude`,
`el`.`time_span` AS `extra`,
`e`.`entity_id` AS `asset_name`,
`el`.`other_id` AS `geozone_id`,
`el`.`group_alias` AS `group_alias`,
`e`.`event_type_id` AS `event_type_id`,
`e`.`entity_type_id` AS `entity_type_id`,
`el`.`some_id` as `some_id`
FROM
(select
`id` AS `event_id`,
`time_stamp` AS `time_stamp`,
`entity_id` AS `asset_name`,
`event_type_id` AS `event_type_id`,
`entity_type_id` AS `entity_type_id`
from
`events`
WHERE
time_stamp >= '2018-01-01'
AND time_stamp <= '2019-06-02'
) AS `e`
JOIN `events_locations` `el` ON `e`.`event_id` = `el`.`event_id`
WHERE
`el`.`other_id` = '1'
GROUP BY
`e`.`event_type_id` ,
`el`.`some_id` ,
`el`.`group_alias`;
The relationship between these tables is 1:1, so, I asked me why is a group by required and I found some duplicated rows, 200 in 50000 rows. So, somehow, my system is inserting duplicates and someone put that group by (years ago) instead of seek of the bug.
So, I will mark this as solved, more or less...
i need write a query with two table, maybe i need pivot query:
First table:
CREATE TABLE `pm` (
`id` int(10) NOT NULL,
`dataoperazione` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
`dataprimanota` date NOT NULL,
`idpuntovendita` int(4) NOT NULL,
`idoperatore` int(4) NOT NULL
)
Second table:
CREATE TABLE `pm_azzeramentofiscale` (
`id` int(10) NOT NULL,
`idprimanota` int(10) NOT NULL,
`cassa` varchar(20) NOT NULL,
`operatore` varchar(100) NOT NULL,
`azzeramento` decimal(8,2) NOT NULL
)
This is my query:
SELECT sum(azzeramento) as incasso, p.dataprimanota as data, p.idpuntovendita
FROM pm as p, pm_azzeramentofiscale as a
WHERE a.idprimanota = p.id
AND YEAR(p.dataprimanota) = 2016
GROUP BY p.dataprimanota,p.idpuntovendita
the result is this format:
| Incasso | Data | IdPuntovendita
1231,12 | 2015-12-12 | 3
6211,12 | 2015-12-12 | 4
but i would like this format
| Data | IncassoPuntovendita3 | IncassoPuntoVendita4
2015-12-12 | 1231,12 | 6211,12
How can write my query ? :D
THanks Regards
if you have a fixed number fo idPuntoVendita you can try this way
SELECT sum(case p.idpuntovendita when 3 azzeramento else 0 end) as incasso_punto_vendita3,
sum(case p.idpuntovendita when 4 azzeramento else 0 end) as incasso_punto_vendita34,
p.dataprimanota as data
FROM pm as p, pm_azzeramentofiscale as a
WHERE a.idprimanota = p.id
AND YEAR(p.dataprimanota) = 2016
GROUP BY p.dataprimanota,p.idpuntovendita;
I have two tables like this.
The 'order' table has 21886 rows.
CREATE TABLE `order` (
`id` bigint(20) unsigned NOT NULL,
`reg_date` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (`id`),
KEY `idx_reg_date` (`reg_date`),
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci
CREATE TABLE `order_detail_products` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`order_id` bigint(20) unsigned NOT NULL,
`order_detail_id` int(11) NOT NULL,
`prod_id` int(11) NOT NULL,
PRIMARY KEY (`id`),
KEY `idx_order_detail_id` (`order_detail_id`,`prod_id`),
KEY `idx_order_id` (`order_id`,`order_detail_id`,`prod_id`)
) ENGINE=InnoDB AUTO_INCREMENT=572375 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci
My question is here.
MariaDB [test]> explain
-> SELECT DISTINCT A.id
-> FROM order A
-> JOIN order_detail_products B ON A.id = B.order_id
-> ORDER BY A.reg_date DESC LIMIT 100, 30;
+------+-------------+-------+-------+---------------+--------------+---------+-------------------+-------+----------------------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+------+-------------+-------+-------+---------------+--------------+---------+-------------------+-------+----------------------------------------------+
| 1 | SIMPLE | A | index | PRIMARY | idx_reg_date | 8 | NULL | 22151 | Using index; Using temporary; Using filesort |
| 1 | SIMPLE | B | ref | idx_order_id | idx_order_id | 8 | bom_20140804.A.id | 2 | Using index; Distinct |
+------+-------------+-------+-------+---------------+--------------+---------+-------------------+-------+----------------------------------------------+
2 rows in set (0.00 sec)
MariaDB [test]> explain
-> SELECT A.id
-> FROM order A
-> JOIN order_detail_products B ON A.id = B.order_id
-> GROUP BY A.id
-> ORDER BY A.reg_date DESC LIMIT 100, 30;
+------+-------------+-------+-------+---------------+--------------+---------+-------------------+------+------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+------+-------------+-------+-------+---------------+--------------+---------+-------------------+------+------------------------------+
| 1 | SIMPLE | A | index | PRIMARY | idx_reg_date | 8 | NULL | 65 | Using index; Using temporary |
| 1 | SIMPLE | B | ref | idx_order_id | idx_order_id | 8 | bom_20140804.A.id | 2 | Using index |
+------+-------------+-------+-------+---------------+--------------+---------+-------------------+------+------------------------------+
Listed above, two queries returns same result but distinct is too slow(explain too many rows).
What's the difference?
It is usually advised to use DISTINCT instead of GROUP BY, since that is what you actually want, and let the optimizer choose the "best" execution plan. However - no optimizer is perfect. Using DISTINCT the optimizer can have more options for an execution plan. But that also means that it has more options to choose a bad plan.
You write that the DISTINCT query is "slow", but you don't tell any numbers. In my test (with 10 times as many rows on MariaDB 10.0.19 and 10.3.13) the DISTINCT query is like (only) 25% slower (562ms/453ms). The EXPLAIN result is no help at all. It's even "lying". With LIMIT 100, 30 it would need to read at least 130 rows (that's what my EXPLAIN actually schows for GROUP BY), but it shows you 65.
I can't explain the 25% difference in execution time, but it seems that the engine is doing a full table/index scan in any case, and sorts the result before it can skip 100 and select 30 rows.
The best plan would probably be:
Read rows from idx_reg_date index (table A) one by one in descending order
Look if there is a match in the idx_order_id index (table B)
Skip 100 matching rows
Send 30 matching rows
Exit
If there are like 10% of rows in A which have no match in B, this plan would read something like 143 rows from A.
Best I could do to somehow force this plan is:
SELECT A.id
FROM `order` A
WHERE EXISTS (SELECT * FROM order_detail_products B WHERE A.id = B.order_id)
ORDER BY A.reg_date DESC
LIMIT 30
OFFSET 100
This query returns the same result in 156 ms (3 times faster than GROUP BY). But that is still too slow. And it's probaly still reading all rows in table A.
We can proof that a better plan can exist with a "little" subquery trick:
SELECT A.id
FROM (
SELECT id, reg_date
FROM `order`
ORDER BY reg_date DESC
LIMIT 1000
) A
WHERE EXISTS (SELECT * FROM order_detail_products B WHERE A.id = B.order_id)
ORDER BY A.reg_date DESC
LIMIT 30
OFFSET 100
This query executes in "no time" (~ 0 ms) and returns the same result on my test data. And though it's not 100% reliable, it shows that the optimizer is not doing a good job.
So what are my conclusions:
The optimizer does not always do the best job and sometimes needs help
Even when we know "the best plan", we can not always enforce it
DISTINCT is not always faster than GROUP BY
When no index can be used for all clauses - things are getting quite tricky
Test schema and dummy data:
drop table if exists `order`;
CREATE TABLE `order` (
`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`reg_date` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (`id`),
KEY `idx_reg_date` (`reg_date`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
insert into `order`(reg_date)
select from_unixtime(floor(rand(1) * 1000000000)) as reg_date
from information_schema.COLUMNS a
, information_schema.COLUMNS b
limit 218860;
drop table if exists `order_detail_products`;
CREATE TABLE `order_detail_products` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`order_id` bigint(20) unsigned NOT NULL,
`order_detail_id` int(11) NOT NULL,
`prod_id` int(11) NOT NULL,
PRIMARY KEY (`id`),
KEY `idx_order_detail_id` (`order_detail_id`,`prod_id`),
KEY `idx_order_id` (`order_id`,`order_detail_id`,`prod_id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
insert into order_detail_products(id, order_id, order_detail_id, prod_id)
select null as id
, floor(rand(2)*218860)+1 as order_id
, 0 as order_detail_id
, 0 as prod_id
from information_schema.COLUMNS a
, information_schema.COLUMNS b
limit 437320;
Queries:
SELECT DISTINCT A.id
FROM `order` A
JOIN order_detail_products B ON A.id = B.order_id
ORDER BY A.reg_date DESC
LIMIT 30 OFFSET 100;
-- 562 ms
SELECT A.id
FROM `order` A
JOIN order_detail_products B ON A.id = B.order_id
GROUP BY A.id
ORDER BY A.reg_date DESC
LIMIT 30 OFFSET 100;
-- 453 ms
SELECT A.id
FROM `order` A
WHERE EXISTS (SELECT * FROM order_detail_products B WHERE A.id = B.order_id)
ORDER BY A.reg_date DESC
LIMIT 30 OFFSET 100;
-- 156 ms
SELECT A.id
FROM (
SELECT id, reg_date
FROM `order`
ORDER BY reg_date DESC
LIMIT 1000
) A
WHERE EXISTS (SELECT * FROM order_detail_products B WHERE A.id = B.order_id)
ORDER BY A.reg_date DESC
LIMIT 30 OFFSET 100;
-- ~ 0 ms
I believe your select distinct is slow because you broke the index by matching on another table. In most cases, select distinct will be faster. But in this case, since you are matching on parameters of another table, the index is broken and is much slower.
in the following scenario:
CREATE TABLE `table1` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`text1` varchar(29) NOT NULL,
`flag` bit(1) DEFAULT NULL,
`reference` int(11) DEFAULT NULL,
PRIMARY KEY (`id`) USING BTREE ,
UNIQUE KEY `idx_text` (`text1`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
INSERT INTO `table1` (id, text1, flag, reference) VALUES
(31486, 'YWXH-D6N4-XXH6', 0, NULL),
(31487, 'CBH0-UJBC-MFTO', 0, NULL),
(31488, 'FRQM-E6MW-6VFE', 1, 1657),
(31489, 'LZOS-EYDT-1BBF', 0, NULL),
(31490, 'D1XQ-YKAX-XQRC', 0, NULL);
CREATE TABLE `table2` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`value1` int(11) NOT NULL,
`value2` int(11) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `value1` (`value1`),
KEY `value2` (`value2`)
) ENGINE=MyISAM AUTO_INCREMENT=20068 DEFAULT CHARSET=utf8 ROW_FORMAT=FIXED;
INSERT INTO table2 (id, value1, value2) VALUES
(1657, 1891, 1748);
-- the tables are shortened from "real" tables, i used SHOW CREATE <table> to create this script.
are the results of the following queries different.
here mysql returns for the record with id 31488 and 31490 the wrong value for the bit-field:
Query 1:
SELECT m.id, m.text1, m.flag, m.reference
FROM table1 AS m LEFT JOIN table2 AS v ON v.id = m.reference
GROUP BY m.text1 ORDER BY m.text1 DESC LIMIT 0, 5;
returns the correct result:
id | text1 | flag | reference
31487 | CBH0-UJBC-MFTO | 0 | NULL
31490 | D1XQ-YKAX-XQRC | 0 | NULL
31488 | FRQM-E6MW-6VFE | 1 | 1657
31489 | LZOS-EYDT-1BBF | 0 | NULL
31486 | YWXH-D6N4-XXH6 | 0 | NULL
while Query 2
SELECT m.id, m.text1, m.flag, m.reference
FROM table1 AS m LEFT JOIN table2 AS v ON v.id = m.reference
GROUP BY m.text1 ORDER BY m.text1 DESC LIMIT 0, 4;
returns this:
id | text1 | flag | reference
31487 | CBH0-UJBC-MFTO | 0 | NULL
31490 | D1XQ-YKAX-XQRC | 1 | NULL
31488 | FRQM-E6MW-6VFE | 0 | 1657
31489 | LZOS-EYDT-1BBF | 0 | NULL
so here is my question:
Im using Joomla CMS, and in the code of the component i can change the whole query except the LIMIT-part.
Joomla add the limit part to the query because of the pagination.
Is there a way to change the query that it works with the LIMIT-command?
oh, my MySQL-Version on Server is 5.1.61 (but this bug still exists on my client v5.5.16)
Your a) not inserting the data correctly - see the BIT data type docs and b) not selecting the data correctly - see the docs on the Bit-Field Literals
You need to insert using the following syntax
INSERT INTO `table1` (id, text1, flag, reference) VALUES
(31486, 'YWXH-D6N4-XXH6', b'0', NULL),
(31487, 'CBH0-UJBC-MFTO', b'0', NULL),
(31488, 'FRQM-E6MW-6VFE', b'1', 1657),
(31489, 'LZOS-EYDT-1BBF', b'0', NULL),
(31490, 'D1XQ-YKAX-XQRC', b'0', NULL);
Then select like this :
SELECT m.id, m.text1, bin(m.flag), m.reference
FROM table1 AS m LEFT JOIN table2 AS v ON v.id = m.reference
GROUP BY m.text1 ORDER BY m.text1 DESC LIMIT 0, 4;
Then it all works as expected
I have a query with ORDER BY name and the index on name is being ignored.
How can I optimize the query to use an index and get rid of Using temporary from EXPLAIN?
I have log-queries-not-using-indexes enabled and I'm seeing this query thousands of times.
Here's the query:
SELECT l.parent_id, j.id, j.location_id, j.currency, j.frequency, ROUND((j.salary_min + j.salary_max)/2) as salary
FROM jobs AS j
JOIN location AS l
ON j.location_id = l.id
WHERE j.salary_min !=0
AND j.status != 'Rejected'
AND l.published =1
AND date_sub(now(), interval 1 month) <= j.effected_date
ORDER BY l.name
The explain:
+----+-------------+-------+--------+----------------------------------+---------------+---------+----------------------------+------+----------------------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+--------+----------------------------------+---------------+---------+----------------------------+------+----------------------------------------------+
| 1 | SIMPLE | j | range | effected_date,location_id,status | effected_date | 9 | NULL | 562 | Using where; Using temporary; Using filesort |
| 1 | SIMPLE | l | eq_ref | PRIMARY | PRIMARY | 4 | esljw_joomla.j.location_id | 1 | Using where |
+----+-------------+-------+--------+----------------------------------+---------------+---------+----------------------------+------+----------------------------------------------+
2 rows in set (0.01 sec)
And the table structure:
CREATE TABLE IF NOT EXISTS `jobs` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`location_id` varchar(255) NOT NULL,
`status` varchar(255) DEFAULT NULL,
`currency` varchar(255) DEFAULT NULL,
`salary_min` int(11) DEFAULT NULL,
`salary_max` int(11) DEFAULT NULL,
`effected_date` datetime DEFAULT NULL,
`frequency` varchar(255) NOT NULL DEFAULT '1',
PRIMARY KEY (`id`),
KEY `effected_date` (`effected_date`),
KEY `location_id` (`location_id`),
KEY `status` (`status`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=10130 ;
CREATE TABLE IF NOT EXISTS `location` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(128) DEFAULT NULL,
`parent_id` int(11) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `name` (`name`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=304 ;
Add published + id composite index to location table
Move l.published =1 condition to the ON clause
This is what you can to do in your case. But probbaly you'll never get rid of using temporary since you're sorting not by primary table, but by joined table.
It's because you've listed job first. Change the order of the tables, like this:
SELECT l.parent_id, j.id, j.location_id, j.currency, j.frequency, ROUND((j.salary_min + j.salary_max)/2) as salary
FROM location AS l
JOIN jobs AS j ON j.location_id = l.id
WHERE j.salary_min !=0
AND j.status != 'Rejected'
AND l.published =1
AND date_sub(now(), interval 1 month) <= j.effected_date
ORDER BY l.name
Try it and post how it goes.
Many times I've done queries where you have proper primary table as first in query, with good indexes, adding STRAIGHT_JOIN alone can fix a query. So, with your existing criteria, you should be good with your date index and use that as the primary criteria... such as
SELECT STRAIGHT_JOIN
L.Parent_ID,
J.id,
J.location_id,
J.currency,
J.frequency,
ROUND(( J.salary_min + J.salary_max) / 2 ) as Salary
FROM
jobs J
join Location L
on J.Location_ID = L.ID
AND L.Published = 1
WHERE
J.Effected_Date >= date_sub(now(), interval 1 month)
AND J.salary_min != 0
AND J.status != 'Rejected'
ORDER BY
L.name