Keep root for administration

The MySQL root account can change users, permissions, databases, and server configuration. Look at what it holds:

SHOW GRANTS FOR 'root'@'localhost';

The answer is essentially everything, on every database, with the right to grant those powers to others. A bug running through that account can damage far more than one application. One malformed query, one SQL injection hole, one leaked .env file — and the blast radius is the entire server, not one database.

That is why this module builds a different setup. Root stays with you, the human administrator, for the handful of tasks that genuinely need it: creating databases, creating accounts, granting privileges. Everything an application does runs through accounts that hold only what that application needs.

Use one account for the running application and another for schema migrations. The application account changes rows. The migration account changes table structure. The split is not bureaucracy — the two jobs have different risk profiles. The application executes untrusted user input all day; the migration tool runs reviewed SQL during a deploy. Give the always-exposed account the smaller set of powers.

You can check at any time which identity a session is using:

SELECT CURRENT_USER();

+----------------+
| CURRENT_USER() |
+----------------+
| root@localhost |
+----------------+

If your application’s connection ever prints root@localhost there, stop and fix the configuration before adding features.

The failure mode you are preventing is easy to picture. An application connected as root plus one injection vulnerability equals an attacker who can read every database on the server, create their own account, and drop whatever they like. The same vulnerability through a restricted account is still an incident, but a bounded one: it touches one database, and only through the privileges you deliberately granted.

The next lessons create those restricted accounts and grant them exactly what they need.