fenway

Or actually escape your input data properly.

Then use a derived table for the second method.

That's too bad. Learn to like it. The worst will happen, forever. Don't do it.

Many alternatives... the sticky has some good resources.

I don't follow... why not join the tables?

That's php's fault.

What you actually want is an index on ( ld_id, ld_keyword )... we can sort of the order by after.

See here.

Yeah, you can't do that in mysql.

CHAR columns for every single one of the above, or leading zeros will kill you.

UTF*?

TLDR.

Show both result sets.

Don't muck around with user data, unless there are strict and tangible formatting requirements.

Please stop posting screenshots for syntax errors -- this is your first & last warning. Also, RTFM -- you need commas between your columns.

OR you could (a) ask for more money or (b) not do the work for no money.

Why don't you have any indexes???

I can't wade through code. Get the raw SQL query, run EXPLAIN on it, and post your results here.

Two things. 1) You can have a primary key across multiple columns. 2) Don't EVER re-use ActionID -- terrible idea -- you'll thank me later.

That sounds wrong... 1s to query a table with const & PRIMARY on small record sets?

Well, 5.1 has index_merge, so you can sometimes get around the "one index per table" issue. Also: That's not actually true -- the optimizer will handle this quite easily. The order only matter when there are not equality constraints; in that case, the constant needs to go first. That is: WHERE column1 = ? AND column2 >= ? will use the index BUT WHERE column1 >= ? AND column2 = ? won't.

Please don't.

Well, you'd have to do the wedate grouping in code.

If you "found" code, then ask whomever "wrote" it. FYI, you can choose to do either.

What day?