fenway

Are you sure your POST hash is "full"?

OK... what do you mean by distinct? One set of votes per company, per rating?

You probably need to specify how to delimit the fields.

No problem... I find it's easier to read "AND", but it's the same. Just remember precedence rules if you mix OR's and AND's.

Like I said, you'd have to check the function spec... I don't know what options they support.

That's right... again, covering indexes are for optimization problems... if you're going to be searching by key2 a lot without key1, then yes, have both. You may also want to read up on the way index_merge works in 5.0.

Numbers are also much faster to join than words.

It's possible that your connect() call could do this, you'd have to check the php spec.

There's no such thing as BIGINT(250)... it's BIGINT(20). And if you want to make it bigger, add UNSIGNED. That's it.

If you're really using the decimal type, AndyB is correct.

Around your date fields.

Ah, Word...yup, plenty of garbage there.

This may be related to another problem that we're working on fixing... stay tuned.

It's some sort of non-ASCII character... where did this text come from? Rich text editor?

Remove the where clause, add each piece the the select column output, you'll be suprised.

Yes... LEFT JOIN.

Might be the max_join_size.

Obviously, a JOIN is "expensive" in the way that you describe it... but denormalization is worse. Especially because you didn't denormalize it on purpose. It's not joins "galore", it's one for each... and with an index, it should be almost instantaneous.

It will only be used if you use the N leftmost keys in a query. If you have (key1, key2, key3), and you try and search for key2 = something, it won't use it. Again, if you're using all three (or N left) parts regularly, it may improve performance. And it's the same size as 3 separate keys.

What does the ratings table look like?

No, I mean a derived table.

Don't think that you can do look aheads in mysql.

Sounds like an linebreak issue

I don't get that... but I get lots of JS errors.

Hmmm... with 30+ fields, and perhaps not a fixed-width record, the server has to do a seek on each one to grab the value from one record then set it on the other one. Have you tried a covering index on ( id, rank )? Then it should be able to grab the value directly from the index without ever reading the table!