SQL 1: 执行时间 0.826秒
SELECT
tenant_id,
o2o_user_id
FROM
crm_point_sync_i2o
WHERE sync_status = 0
AND next_execute_time < NOW()
AND tenant_id IN
(SELECT
tenant_id
FROM
crm_config
WHERE is_enable = 1
AND is_sync = 1)
ORDER BY try_times ASC,
update_time DESC
LIMIT 1000; SQL2 , 在sql1的基础上把排序去掉了,按理说,应该更快啊,怎么慢这么多: 执行时间2.212 秒
SELECT
tenant_id,
o2o_user_id
FROM
crm_point_sync_i2o
WHERE sync_status = 0
AND next_execute_time < NOW()
AND tenant_id IN
(SELECT
tenant_id
FROM
crm_config
WHERE is_enable = 1
AND is_sync = 1)
LIMIT 1000执行计划如下:
SELECT
tenant_id,
o2o_user_id
FROM
crm_point_sync_i2o
WHERE sync_status = 0
AND next_execute_time < NOW()
AND tenant_id IN
(SELECT
tenant_id
FROM
crm_config
WHERE is_enable = 1
AND is_sync = 1)
ORDER BY try_times ASC,
update_time DESC
LIMIT 1000; SQL2 , 在sql1的基础上把排序去掉了,按理说,应该更快啊,怎么慢这么多: 执行时间2.212 秒
SELECT
tenant_id,
o2o_user_id
FROM
crm_point_sync_i2o
WHERE sync_status = 0
AND next_execute_time < NOW()
AND tenant_id IN
(SELECT
tenant_id
FROM
crm_config
WHERE is_enable = 1
AND is_sync = 1)
LIMIT 1000执行计划如下:
这个改变了取数据的顺序,所以不加 ORDER BY 不一定快
不加order by不一定快,那么为啥加了比不加要快很多
不加order by不一定快,那么为啥加了比不加要快很多而且执行计划差别那么大
不加order by不一定快,那么为啥加了比不加要快很多而且执行计划差别那么大另外,我现在把limit去掉,效果也是一样,加了order by快很多
说说理论吧
有 ORDER BY 或 LIMIT 都可能导致执行计划差异,所以效率有差异是正常的,关键是看那种情况的执行计划更符合效率要求
毕竟执行计划是根据语句和表结构、统计信息评估出来的一种应该最佳的执行方式,但它只是应该,不是绝对
以虽然不加 ORDER BY 应该会快一些,但这并不绝对
你QQ多少,我加你,QQ讨论下