Many can be found online that argument:
If the query two tables of comparable size, then use in and exists little difference.
If the two tables in a small, a large table, the table subqueries with EXISTS large, with a small table subqueries in:
Example: Table A (small table), Table B (large table)
. 1:
SELECT * a from WHERE cc in ( SELECT cc from B) inefficient, uses the index table cc column a;
SELECT * from a WHERE EXISTS ( SELECT cc from B WHERE cc = a.cc) high efficiency, the use of table B index cc column.
Instead of
2:
SELECT * from B WHERE cc in ( SELECT cc from A) with high efficiency, the use of the index table cc column B;
SELECT * from B WHERE EXISTS ( SELECT cc from A WHERE cc = B.cc) inefficiencies , use the index on the table a cc column.
The following statement is executed optimization:
select count(uid) from user where uid in (SELECT did FROM demo);
select count(uid) from user where exists (SELECT 1 FROM demowhere demo.did = user.uid);
1. Note that the reason is slow when compared to the interior of each external operation requires traversal of a table, another method may be employed, one nested subquery, avoiding multiple traversal operation
SELECT count(did) FROM demo where exists (SELECT uid FROM (SELECT uid from user) as b where b.uid = demo.did);
2. The second query optimization is the first child in the statement is executed, using GROUP_CONCAT to connect the field,
If the string length is not enough may be used: SET SESSION group_concat_max_len = 102400;
Original sql:
SELECT
c.id
FROM
c 此表有712995条数据
LEFT JOIN u ON c.user_id = u.id
LEFT JOIN doc ON c.doctor_id = doc.id
LEFT JOIN s ON c.meal_id = s.id
WHERE
s.renew = 1
AND c.orderstatus = 1
AND c.endtime < UNIX_TIMESTAMP()
AND c.org_type = 'c'
AND u.is_doctor = 0
AND u.active = 1
AND doc.is_doctor IN (4, 5)
AND doc.is_family_doctor = 1
AND doc.active = 1
AND c.user_id NOT IN (
SELECT
user_id
FROM
d 此表有934455条数据
WHERE
d.log LIKE '%结束'
);
- execution time 2.265s
Optimized:
SET SESSION group_concat_max_len = 102400;
The GROUP_CONCAT the SELECT (user_id) the WHERE the FROM D d.log the LIKE 'end of the%'; - performed 0.521s
SELECT
c.id
FROM
c
LEFT JOIN u ON c.user_id = u.id
LEFT JOIN doc ON c.doctor_id = doc.id
LEFT JOIN s ON c.meal_id = s.id
WHERE
s.renew = 1
AND c.orderstatus = 1
AND c.endtime < UNIX_TIMESTAMP()
AND c.org_type = 'c'
AND u.is_d = 0
AND u.active = 1
AND doc.is_d IN (4, 5)
AND doc.is_f_d = 1
AND doc.active = 1
AND c.user_id NOT IN (24986,24986,24986,24986,24986,24986,..............................................大概5千个id);
- execution time 1.579s
Less 0.686s execution time, but GROUP_CONCAT (user_id) also performed 0.521s, so overall there is no time difference (the current order of magnitude),
And after a string of the need to consider the size of the problem.
At present it is understood that, after a time then carefully pondering.