fenway

In general, when you use GROUP BY, you can't rely on the values on any non-aggregated column.

How are score and score2 different?

You might want to read this.

But you have 3 tables.

Of course it returns more than one row -- that's the whole point -- first get the streak example to work, then merge it back. Since there's no sample data, I can't help you.

First, the use of RIGHT JOIN is killing me -- switch the LEFT JOIN like the rest of us -- of course, you're never actually using the non-matching aspect, so INNER JOIN is the better choice here. Second, getting the most recent for each thread is not achieved with group by -- you need to self-join and find the records that have no messages with more recent dates. I've posted this kind of solution at least twice in the last week.

By the looks of it, the query conditions are totally different.

Fulltext searches do stemming, but they won't correct misspellings.

You're supposed to use SUM() and IF(). e.g. SUM( IF( `status` = 'sold', 1, 0 ) )

No -- the "other option" you have is to number them properly -- with a counter. gizmola has given you a way to fix this once -- but don't.

Just add a SUM() and a group by.

Two problems. One, FIND_IN_SET() can only find one value at a time. Second, it needs to be comma separated, so if you're really going to hack it to make it work, you'll need to use REPLACE() to swap colons for commas.

Did you try that query? Because there is no regex that will do this quickly.

You can combine those into a single statement.

Well, if you can post the logic behind the solution, that will suffice.

I don't understand why you're adding rows with no values.

It usually indicates a design flaw.

Those constraints don't enforce UNIQUEness unless you ask for it. I'm not sure why you create an empty row first -- but if you do so, you'll need to NULL out those FKs. But again, it sounds like a mistake.

Why not? Please read the article http://psoug.org/definition/DISTINCT.htm Um, no -- this isn't ORACLE.

TLDR -- where are you at now?

Your DB layer should handle this for you -- otherwise, you'll forget one time.

Chinese is likely being stored as multi-byte characters -- either 2 or 3 -- and if it's 3, 100 won't work. At least pick a number that's a multiple of both 2 and 3.

Sure can combine DISTINCT with * -- but if you have a UID in that table, the DISTINCT isn't doing anything. Explicitly list the fields you want back, and you'll be pleasantly surprised.

The sticky for this board covers simple debugging techniques like this.

Sorry, I don't understand the problem.