fenway

That is very strange... which table type?

Join how?

How is this different from your initial code?

What are you trying to update that's in both tables? I'm confused.

To represent the same thing? I like keeping the names the same.

Not really -- inexact matches are poor to begin with. Why is your data stored this way?

Echo the sql statement... you sure you're getting the right $id?

Not without a stored procedure.

Post the EXPLAIN... maybe you're missing indexes.

If you'd like, you can combine them into a single "statment", but it would still be running multiple queries... I suppose you'd save the overhead of multiple query() calls. You can do this: ( SELECT COUNT(*) FROM gift_items ) AS gift_items, ...... ( SELECT COUNT(*) FROM collectibles ) AS collectibles FROM DUAL

LIKE is instead of = Only other robust option is Lucene.

Drop the single quotes...

There are some stickies on DB normalization... but in general, yes.

Sometime localhost and 127.0.0.1 on windows aren't the same.

You can use wildcards to join 2 tables, it's just not efficient.

Stop right there... you need to be running COUNT(*)s, not getting back all of the data and then throwing it out... your current implemention is likely much slower as a result.

I don't see you ever retrieving the columns from the result set your obtained.

Let's start again... post the code you have now.

That's because the LEFT JOIN makes checking any rows from that table meaningless... when you switched it the checking the non-joined table, it was fine. Separate? please cxplain.

LIKE is just returning true or false.

You can combine multiple conditions in the ON clause like in a WHERE clause.

Well, you can recompile the server to change the minimum length....

Sorry, replace = with IN, my bad.

This is the syntax: GRANT ALL ON mydb.* TO 'someuser'@'somehost'; Not the quoting before and after the @ sign.

The first query is good -- you see how there's no filesort, and the key isn't NULL? The second query is bad for two reasons: first, there's no index on the members (table scan = ALL)... second, you're using a dependent subquery, which si executed once for EVERY matching row of members -- or ~2600 times! Could you explain what you're trying to query? For the 3rd one you still have no index usage -- add an index on friendID for the members_detailed table, and add a composite index for ( theirs, yours ) to added. Also, your queries would really benefit from table aliases and column prefixes.