Morning Jorg, Thanks for the reply.
> The "limit" clause restricts the data returned, but not the data examined.
> You ask the server to examine a certain set of rows ("where ..."),
> sort it ("order by ..."),
> and then to return a limited number of these rows ("limit ...").
>
> As the data only exist in some other order and you (probably) do not
> have a way to access them in the order desired (or do you have an index
> on "bluetooth_session.created"?), the server must first sort all
> qualifying rows. This is where it needs so much space.
This makes perfect sense, I see what you mean about the fact that the data
has to effectively be collated in its entirety before it is ordered and
limited, that's a very fair statement.
> Somebody else has already commented on the "limit" clause you use,
> I need not repeat that.
They did indeed, I hadn't noticed this myself, the SQL is produced by an ORM
so I'll examine how I'm using that, thanks to all who pointed that one out.
> I strongly suspect an index on "bluetooth_session.created" would help,
> both in evaluating the "where" condition and in avoiding the sort for
> "order by", and so both reduce the time and avoid the temp space.
I can see your point on this, I've not worked with index's at all at this
point in time so I'll give them a shot and see what difference that makes,
the created date definitely makes a very strong candidate as this is
generally how the data is queried, so that'll be my first index, I also
regularly query on the address column so I'll be sure to try indexing that
too.
> Disclaimer: Not tested, not checked - just assuming.
I really appreciate the suggestions, I certainly see the logic in them,
let's hope they bare fruit :-)
Cheers,
Heston
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
