一个SQL order by的优化

sunnyfun

不管丢不丢失，多出来也不好，呵呵
要把多出来的东西去掉光LIMIT不行吧
主要还是要看外键约束是否严格了。

Edengundam

原帖由 sunnyfun 于 2008-6-3 14:53 发表
不管丢不丢失，多出来也不好，呵呵
要把多出来的东西去掉光LIMIT不行吧
主要还是要看外键约束是否严格了。

不会丢, 只会多, 外键不严格不会影响查询正确性.

因为最初查询的前20名现在一定包含, 而且只可能变多.

原来order by下来可能是111122223333
我如果先做可能是1234567, 但是经过LEFT JOIN后, 我依然能得到所有的11112222333344567, 这个过程结果集只会变成超集, 其实就相当于将原来的前二十名做distinct, 然后重新做, 只多不少, 因为LEFT JOIN虽然会引起order by字段可能出现重复, 但是如果在之前把前二十名都取出来, 那么只会增加.

整体的结果集变小了, 无论是JOIN还是ORDER BY, 速度都会更快, 减少了I/O.

carny

把 order by 那部份在database engine的 C Language , 改寫為Assembly,
應可提速10倍以吧

Edengundam

原帖由 carny 于 2008-6-3 17:13 发表
把 order by 那部份在database engine的 C Language , 改寫為Assembly,
應可提速10倍以吧

如果真能提高, 早就有人改写了. 汇编不是万能的, 不过在一些特殊场合, 基于解释器的比重汇编的速度慢很多. 不过数据库不使用上述情况.

MySQL编译开关有一些字符串比较的汇编代码, 这种级别优化只能针对特定应用.

carny

有人提反對, 改Assembly,
那就走另一條路, 加index   (條件為where 和order by 那些欄位所組成的combo index)
應可提高10倍以上的速度

nogroup

结果集从我的查询结果来看,的确没有丢失.
大家讨论的层面越来越深入了,我快看不懂了.

songwin88

学习

yueliangdao0608

原帖由 Edengundam 于 2008-6-3 11:57 发表



首先ORDER BY没有顺序保证, SELECT也一样.

其次, LIMIT在最后做, ORDER BY产生的结果可能包含同一个值的多条记录.
但是先做LIMIT, 只会增加最终的结果集元组数量, 如果多了再LIMIT一次即可.

根据 ...

The results are not always the same between each other.
I did test this a long time ago.