fenway

Yes, that would VERY slow! Why does it matter if it's "repeated"

mysql_query() will return TRUE on success... don't know why you think otherwise.

OMG, please stop. Echo the actual sql statment that you're sending to the server, and post the error message you get -- no attachements.

Well, you can "force" the other index to be used, but I'm not sure it would be faster... try it and see (make sure the cache is off). EXPLAIN SELECT * FROM user_history FORCE INDEX( user_history_datetime ) WHERE user_id=72 ORDER BY user_history_datetime LIMIT 0,25

The code looks fine...

I'd prefer to "wrap" it in the delimeter too, but it's unlikely to be an issue for formatted data like IPs.

Ugh... use DATE() functions for what they were meant for!

So, solved?

You're mixing ORs and ANDs without parens.

Version 6, I think....

You don't want to get rid of "using where" -- otherwise you'll have a full table scan. As for the filesort, it's not using the index on user_history_datetime because it has "decided" that it's faster to narrrow down the table using the user_id instead. How big is your table? It seems to find ~30K matching user_id rows. Have you run OPTIMIZE lately? What table type?

Say what?

If you had both "lists" in a table, the comparison would be trivial.

Listen to the error... you didn't select a db.

Yes, you can't use GROUP BY and retrieve non-aggregate columns.

I don't understand.

The adjacency list model (the one you are using) makes getting all parents or descendants a complex problem -- you'll have to self-JOIN as many times as you think the list is deep.

Dynamic fields/tables in a bad idea.

No... only inserts can be truly delayed, AFAIK.

You'll need a join for each of the "AND" conditions.... there are many threads that cover this topic.

You're missing a join condition.

I don't understand your question.

In the echo. Alternatively, $users = mysql_result($sql, 0, 0); Will work too.

Yikes.

Or by reading the stickies.