fenway

Does the EXPLAIN confirm this?

Look here for the sql-only version -- though I haven't used it much.

Why are you comparing the HEX?

I simply meant the style of using "--optionname=optionval", vs. "-o optionVal".

That's a good start.. any sample data?

Echo the string that your'e sending to mysql_query()

Since we have no idea what to do with all of that code, you'll have to actually explain your problem.

That should always be the FIRST thing you do.

Could you post your "solution"?

Simplify that for us, or post the full table structures... it's hard to guess.

I'm not a big fan of "ALL", but it's fine for testing.

You need a JOIN: select d.name from domains as d inner join logins as l using (domain_id) where l.username = <whatever>

Not true. Why aren't you using the FULLTEXT index that you actually have?

Could you post the table structure (CREATE TABLE syntax) and some sample data? I'll see what I can come up with... which version, btw?

Well, first you have to store the encrypted password, say with SHA1/MD5 -- but in php... then you INSERT into the DB directly, so the plaintext password is never "sent". You simply do the opposite in reverse.

Depends on your cardinality of type & status... if they are poor, it shouldn't really use them, but if there's just one, then perhaps it's better. You can also try adding date as the *first* column in the index....

They should be much faster, since they're pre-compiled, but I haven't benchmarked this.

There are also mysql UDFs for JSON.

Definitely for InnoDB... but even for MyISAM tables, it really depends how often this query will be removed from the query cache.

Assuming they both can talk via ODBC, you can connect between them.. but as for conversion, I have no idea.

Not sure... CONCAT() only returns NULL as a whole occasionally, not just a single argument. Same for CAST()... strange.

That's because after the union the fields "lose" their prefix... why not: ( SELECT title FROM bedroom WHERE title LIKE '%".$keywords[$i]."%' ) UNION ALL ( SELECT title FROM dining WHERE title = '%".$keywords[$i]."%'"; )

Not the best approach, depending on how many dupes you have... another option to do get distinct results from the 2nd table *first*, and then join it back to the 1st table.

I think the reference was to access, not arabic... >_<

There are GRANT statements for this purpose.