fenway

You need to move e.type = 1 to the ON clause.

That won't work... you'll end up with too many rows. It's probably just easier to use subqueries to generate a pivot table.

You are correct, FULLTEXT is for myisam only.

They are stored in time-zone-independent format (call it GMT)... but only if you stored them properly.

MySQL has convienient functions for both (a) switch any date/time to a given timezone and (b) setting the timezone for the current connection, in which case it's all handled for you.

I'm confused about your example... did you not suggest and index with 3 keys?

I suppose you could use a BEFORE INSERT trigger and check; to be honest, I'm not really using 5.0, so I haven't played much with them.

You can't do that with an index... maybe with a trigger.

You may want to read this.

Well, the index structure is fundamentally different. Wait a minute, is binary logging enabled?

Not even theoretically, since it would do the conversion regardless.

I don't think I've ever had that many rows in a table... I'd be curious if it would take the same time to re-build an myisam index.

Why do you ask? The keywords are not case-sensitive...

It depends how the table is set up... if you always tend to pull a single column based on the value of a few others (e.g. "name" in a lookup table with two uids) then it can be quite helpful. Otherwise, covering indexes are very useful for group by / order by operations, since it can often prevent a filesort.

You mean != ? Unless it's via a LEFT JOIN.. IS NULL.

You are correct... a covering index can only be used if all of the keys of the index are either in the where clause or the select list.

Really? Again? Someone just asked this question.

Well, in theory you could use ZEROFILL, but I would recommend use a normal column and then simply LPAD() it on the way out.

Actually, I really like it too...good stuff.

You don't have to physicallycombine the columns...

If you have a multi-column unique index, then it will trigger dupe key.

Yes, that's the idea. It's a type of storage engine... see here.

Replace this: AND td.tid = '312' OR td.tid = '221' OR td.tid = '222' with this: AND ( td.tid = '312' OR td.tid = '221' OR td.tid = '222' ) or even better: AND td.tid IN ( '312' , '221' , '222' )

Well, assuming you have a new version of mysql, you can use a CSV as a table... that should make it easy to update every column from every user_id found in the club record.

OK, but obviously you can somehow identify which changes are associated with which records?