fenway

You'd have to look into horizontal partitioning.

Take a look here.

The final decision is yours...

Try this (untested); SELECT t.id, t.owner FROM trades AS t INNER JOIN ( SELECT id FROM useritems WHERE itemid='$itemiid' AND location='Gone' ) AS u ON ( t.item1=u.id OR t.item2=u.id OR t.item3=u.id OR t.item4=u.id OR t.item4=u.id OR t.item4=u.id ) GROUP BY t.id

There are some stickies on basic JOIN syntax with examples. Basically, you're running 2 queries -- one to get the uids, and then the group by one. You don't need to do this in 2 separate steps.

Glad it's performing better... the way to handle this is to run the first 0.3 second query without it, then get back info UIDs, and then run a second query on the info table -- this can be a subquery, of course, or a derived table (probably better). BTW, ranges are very difficult to optimize.

I was referring to the situation where you would need to specify additional info about each permission, not just y/n.

I can think of lots of reasons why I'd need to access individual permissions.

Try using a JOIN.

Sorry, my bad -- I saw the NULL and simply assumed that meant that was the key. So why so many rows? Oh, you have a limit, so the rows is meaningless. Drop all where clauses except for sessions-based fields, and see what explain thinks.

IMHO, that's short-sighted -- and as I said before, a SET is just a haphazard implementation of a BIT mask.

You can see here -- I still wouldn't recommend it.

I still don't understand why it won't use an index on the sessions table... you can always force it to use a particular index, but it should know...

I entirely disagree -- use a BIT field if you really want to save space.

Well, you have straight join hints there... switch as INNER JOIN. Then remove parts of the where clause / order by clause until you get the indexing you want, then add the mback.

SETs are very annoying... with ENUM, as long as you add to the end, your data should stay intact.

I see... nonetheless, I don't understand why it's "using index"...

My guess is that the event handler isn't returning a boolean properly.

Say what? You mean the .src or the .name?

Not impossible, just difficult, since not all properties can be accessed / changed... see here.

Definitely the second one -- NOT IN is terrible.

They didn't "break it" -- the comma operator was always a bad idea

You first.

Don't double-post.

I'm confused about "using index" on the sessions table... it doesn't seem to be using any index (e.g. for last_on).