fenway

Not sure which part is causing problems for you... there's a lot going on there.

You can use user variables for "row-based" counts/sums. As for the import, I assume it's CSV-able, and mysql actually has such a table type (or LOAD DATA INFILE from any tab-separated file).

I've no idea what you've done... but you have a union...

SELECT count(*) as num FROM c5t_comment WHERE comment_identifier='/hotels/anglo.php' AND comment_status = 0

Don't use php based counters.

I'll take a look...

Yeah, no kidding, I had do some reporting and to get the DATE part of a DATETIME field I had to do this: SUBSTRING( CONVERT(varchar, l.triggered_on, 20 ), 1, 10 )

Right... but you wouldn't have a second 1002/2 row if the unique index was present.

Hmmm... maybe all aggregate function always return a single row, like count, sum, avg, etc... and group_concat behaves like one of these too!

Look it up first...

TABLE AS ALIAS. hwz_postcodes AS dest

Varibles? No variables... it's TABLEALIAS.COLUMNNAME.

I don't really see how that could be much better... not sure I understand that new column you made.

You're passing the entire php line to mysql... there's an assignment!

NULL row? From just a single table? Sounds implausible... and select * doesn't give you a null row?

You can have a unique index that spans multiple columns...

Matters to everyone else other than you... how?

That won't work because you have php code in your sql statement. You need to convert that php code into the equivalent sql code with SUBSTRING() and LOCATE().

What do you mean? If there's no match, you shouldn't get any rows back, group_concat() or not...

You're using != , so no index... inner join is probably what you want vs. left, and order by rand() is poor as well.

No idea... post the EXPLAIN

Replace each comma with the words "INNER JOIN", then move each corresponding WHERE clause portion to an ON clause. But it won't be any faster, just easier to read.

MySQL has substring() function too....

FYI, InnoDB is much slower that MyISAM for typical web applications.

Ah yes, I forgot about that bug... came across that one a long time ago while using an ODBC driver using an older version of the connector (not that I can find any refererence to it anymore). Apparently, it gets confused and "forgets" to stringify it.