fenway

You're new here -- please share how you "figured it out" next time -- even if it only took 3 minutes for you, others may benefit from your post. The issue here was quoting the column names.

If you post your entire code one more time, I'm going to lock this thread for good -- just post the relevant code snippet, nothing more. If you feel the urge to include the entire script, use an attachment.

A primary key is just a special unique index, at its core. A foreign key is way to ensure that cross-referenced values between tables stay consistent (i.e. when the parent gets updated, the child tables do as well). It is often true that the index required in the referencing table is often the PK, but there's no requirement for it to be. Every InnoDB table requires a PK -- and it's a good idea to pick one yourself, or InnoDB will make a poor choice for you. MyISAM can omit the PK, but it's rarely a good idea for most tables. In terms of multi-table queries, once again, indexes are required for these to perform well -- so a PK can often be used.

Welcome aboard the SS Freak.

Sorry, I don't understand the question....

Just a note of caution -- GROUP_CONCAT has a maxlength of 1000 characters by default, so if you have a great many records, it will be silently truncated.

Not that I understand why you need this -- but depending on what you're actually doing, you can use some sort of function to apply, seeded for each user/timestamp/whatever, which you apply to the PK.

So nice of you to post the solution.

Searching with LIKE is terrible on any meaningful amount of data. Using FULLTEXT isn't useful for anything but prose. There are plenty of algorithms you can use -- but what are you trying to achieve? True full-text search, or something else?

That's because you're not supposed to write statements that refer to multiple databases when using replication -- it's just asking for trouble, and it's well documented. As for the slave thread, the whole point is to keep the lag to a minimum -- don't try and mess with it.

I'm certain you want WHERE clauses on all of your UPDATE statements. And I don't follow what doesn't work -- don't show me all your code, it doesn't help.

Sounds like a terrible idea.

I don't know what you're talking about -- I'm referring to the user passwords, not your DB login password. That has nothing do with firewalls.

In that case, your passwords are case-insensitive, too -- are you aware of that? That makes them much less secure.

Are you using a case sensitive collation? Do you want passwords to end up in query logs and processlists? I think not.

Also, that's not a secure way to log in users.

TLDR -- you'll need to simplify this example if you want some help -- I can't parse that in my head.

Updating in a loop is usually reserved for transaction contention -- but I don't see any evidence of that in this case.

That display width is pretty much useless -- and definitely meaningless without ZEROFILL -- which no one should use anyway.

For the SET column type -- obviously. And if you think millions of rows is a bad idea, maybe you shouldn't be using a DB at all.

Sounds like maybe you have more than one DB server running.

I'm certain these tools have documentation.

I also keep reminding everyone about the CSV engine type.

+1 -- events are way too fragile, and hidden.

I'm not going to tell you how to perform MySQL injections -- but suffice it to say that most of them have to do with the WHERE clause.