添加链接
link管理
链接快照平台
  • 输入网页链接,自动生成快照
  • 标签化管理网页链接
相关文章推荐
奔跑的大脸猫  ·  eb macro language - ...·  3 月前    · 
耍酷的豌豆  ·  how to extract ...·  4 月前    · 
英姿勃勃的苦瓜  ·  IBM Cloud Docs·  7 月前    · 
Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Learn more about Collectives

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Learn more about Teams SELECT CourseID, COUNT(*) AS LessonCnt FROM CourseSection GROUP BY CourseID USING(CourseID) WHERE UserCourse.UserID = 8810

If I run this, it executes very quickly (.05 seconds roughly). It returns 13 rows.

When I add an ORDER BY clause at the end of the query (ordering by any column) the query takes about 10 seconds.

I'm using this database in production now, and everything is working fine. All my other queries are speedy.

Any ideas of what it could be? I ran the query in MySQL's Query Browser, and from the command line. Both places it was dead slow with the ORDER BY .

EDIT: Tolgahan ALBAYRAK solution works, but can anyone explain why it works?

Why it works? a sub-query takes the result in a result set, and ordering a result-set is much faster than having the default query execution have count in ordering along the way. Stijn Sanders May 19, 2009 at 21:00 SELECT CourseID, COUNT(*) AS LessonCnt FROM CourseSection GROUP BY CourseID USING(CourseID) WHERE UserCourse.UserID = 8810 ) ORDER BY CourseID Huh, that works (makes it execute fast). Do you know why though? I've never had to do that before. Dude May 19, 2009 at 19:51 40k isnt that many records; typically have to deal with millions soyour milage may vary but this may help improve the performance further on this as the joins will be done on a reduced dataset. ... FROM (Select * from UserCourse Where UserID = 8810 ) UserCourse u07ch May 19, 2009 at 19:54 tvanfosson, I always thought the ORDER BY was processed after the results were returned. I guess that isn't necessarily the case. I'll have to investigate a bit more. Thanks. Dude May 19, 2009 at 20:07

You are selecting from " UserCourse " which I assume is a joining table between courses and users (Many to Many). You should index the column that you need to order by, in the "UserCourse" table.

Suppose you want to " order by CourseID ", then you need to index it on UserCourse table.

Ordering by any other column that is not present in the joining table (i.e. UserCourse) may require further denormalization and indexing on the joining table to be optimized for speed; In other words, you need to have a copy of that column in the joining table and index it.

The answer given by Tolgahan Albayrak, although correct for this question, would not produce the desired result, in cases where one is doing a "LIMIT x" query.

Bizarre, I just ran into a similar issue and updating the statistics did fix this. We had to restore a database backup for this environment a couple days ago which probably caused this in the first place. Wotuu Dec 31, 2021 at 10:49

Realise answer is too late, however I have just had a similar problem, adding order by increased the query time from seconds to 5 minutes and having tried most other suggestions for speeding it up, noticed that the /tmp files where getting to be 12G for this query. Changed the query such that a varchar(20000) field being returned was "trim("ed and performance dramatically improved (back to seconds). So I guess its worth checking whether you are returning large varchars as part of your query and if so, process them (maybe substring(x, 1, length(x))?? if you dont want to trim them. Query was returning 500k rows and the /tmp file indicated that each row was using about 20k of data.

Today I was running into a same kind of problem. As soon as I was sorting the resultset by a field from a joined table, the whole query was horribly slow and took more than a hundred seconds.

The server was running MySQL 5.0.51a and by chance I noticed that the same query was running as fast as it should have always done on a server with MySQL 5.1. When comparing the explains for that query I saw that obviously the usage and handling of indexes has changed a lot (at least from 5.0 -> 5.1).

So if you encounter such a problem, maybe your resolution is to simply upgrade your MySQL

Thanks for contributing an answer to Stack Overflow!

  • Please be sure to answer the question . Provide details and share your research!

But avoid

  • Asking for help, clarification, or responding to other answers.
  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers .