Comments on: Using index for ORDER BY vs restricting number of rows. http://www.mysqlperformanceblog.com/2007/02/16/using-index-for-order-by-vs-restricting-number-of-rows/ Everything about MySQL Performance Tue, 02 Dec 2008 16:11:17 +0000 http://wordpress.org/?v=2.5.1 By: peter http://www.mysqlperformanceblog.com/2007/02/16/using-index-for-order-by-vs-restricting-number-of-rows/#comment-52959 peter Fri, 16 Feb 2007 22:39:33 +0000 http://www.mysqlperformanceblog.com/2007/02/16/using-index-for-order-by-vs-restricting-number-of-rows/#comment-52959 Alexey, This is just example I used. Imagine real case with for example 10 different filters and 5 fields you may sort on... you simply can't build indexes to cover all combinations and as soon as you skip something you start to get the problem. It may be with sorting by the date for example etc. You're right about sorting - priority queue (for example) based sort would be possible to use without changing semantics for many LIMIT queries. It was even discussed for years by Optimizer team but was not done. This would not exactly help in this case though as even with partial sort you will need to scan full result set while with scan in index order you can stop as soon as needed number of rows was delivered. Alexey,

This is just example I used. Imagine real case with for example 10 different filters and 5 fields you may sort on… you simply can’t build indexes to cover all combinations and as soon as you skip something you start to get the problem.

It may be with sorting by the date for example etc.

You’re right about sorting - priority queue (for example) based sort would be possible to use without changing semantics for many LIMIT queries. It was even discussed for years by Optimizer team but was not done.

This would not exactly help in this case though as even with partial sort you will need to scan full result set while with scan in index order you can stop as soon as needed number of rows was delivered.

]]> By: Alexey http://www.mysqlperformanceblog.com/2007/02/16/using-index-for-order-by-vs-restricting-number-of-rows/#comment-52941 Alexey Fri, 16 Feb 2007 22:10:23 +0000 http://www.mysqlperformanceblog.com/2007/02/16/using-index-for-order-by-vs-restricting-number-of-rows/#comment-52941 Why not change `cat_id` index to include price also? like (`cat_id`,`seller_id`, `price`)? Also, I've always wondered why don't DB developers implement something like "partial sort" algorithm, which doesn't sort the whole set, but instead picks top N values. I think such algorithm is O(N) and also it doesn't any tempfiles, one simple scan. Why not change `cat_id` index to include price also? like (`cat_id`,`seller_id`, `price`)?

Also, I’ve always wondered why don’t DB developers implement something like “partial sort” algorithm, which doesn’t sort the whole set, but instead picks top N values. I think such algorithm is O(N) and also it doesn’t any tempfiles, one simple scan.

]]> By: Dmitri Mikhailov http://www.mysqlperformanceblog.com/2007/02/16/using-index-for-order-by-vs-restricting-number-of-rows/#comment-52934 Dmitri Mikhailov Fri, 16 Feb 2007 21:35:56 +0000 http://www.mysqlperformanceblog.com/2007/02/16/using-index-for-order-by-vs-restricting-number-of-rows/#comment-52934 Runtime optimization in OLTP systems has always been expensive; I always try to turn CBO off by all means available. There is nothing wrong about it if: a) the data distribution is well known and b) is not going to be changed and (c) the database design is solid. Runtime optimization in OLTP systems has always been expensive; I always try to turn CBO off by all means available. There is nothing wrong about it if: a) the data distribution is well known and b) is not going to be changed and (c) the database design is solid.

]]> By: peter http://www.mysqlperformanceblog.com/2007/02/16/using-index-for-order-by-vs-restricting-number-of-rows/#comment-52790 peter Fri, 16 Feb 2007 16:24:12 +0000 http://www.mysqlperformanceblog.com/2007/02/16/using-index-for-order-by-vs-restricting-number-of-rows/#comment-52790 Sheeri, Yes that is the bummer with force index hint. It is helpful it you know it is best plan to run the query for all constants, if it is not you're in trouble. Sheeri,

Yes that is the bummer with force index hint. It is helpful it you know it is best plan to run the query for all constants, if it is not you’re in trouble.

]]> By: Sheeri http://www.mysqlperformanceblog.com/2007/02/16/using-index-for-order-by-vs-restricting-number-of-rows/#comment-52789 Sheeri Fri, 16 Feb 2007 16:18:42 +0000 http://www.mysqlperformanceblog.com/2007/02/16/using-index-for-order-by-vs-restricting-number-of-rows/#comment-52789 You have to make sure, when you're doing something like forcing an index due to the character of your data, that you check and make sure the character of the data does not change. You have to make sure, when you’re doing something like forcing an index due to the character of your data, that you check and make sure the character of the data does not change.

]]>