Accounts and privileges
A MySQL account is identified by a user name and a host component, such as a connection origin pattern. The host part matters: accounts with the same user name but different hosts can have different credentials and grants. Privileges determine which operations an authenticated account may perform, such as reading a schema, modifying rows, creating tables, or executing a stored routine. Authentication answers who connected; authorization determines what that account may do.
Use distinct accounts for application runtime, schema migrations, human administration, reporting, and replication where appropriate. A web application's normal runtime account rarely needs global administrative privileges or the ability to drop tables. Separate identities limit the damage from leaked credentials, compromised application code, and accidental commands. They also make audit trails more useful because actions can be associated with an operational role.
Create accounts and grant narrowly
CREATE USER 'shop_app'@'10.%'
IDENTIFIED BY 'replace-with-a-secret-manager-value';
GRANT SELECT, INSERT, UPDATE, DELETE
ON shop.*
TO 'shop_app'@'10.%';The password string is illustrative and must not be used as an actual credential. Generate unique secrets and deliver them through a protected secret manager or deployment mechanism. Restrict the host pattern to the application network rather than assuming any host is safe. Schema-level grants are narrower than global grants. Grant only the actions the service needs, and avoid granting schema-changing privileges to the runtime identity when a separate migration process can own DDL.
Review effective permissions with SHOW GRANTS and test from the same network and client configuration the service uses. A grant that looks correct may not apply to the account that actually matched because host patterns and authentication configuration are involved. Avoid broad wildcard grants as a quick fix for connection errors; identify the intended account and grant scope.
Roles reduce repeated grant administration
A role is a named collection of privileges that can be granted to users. Roles help administrators assign consistent capabilities to multiple accounts, such as a read-only reporting role or an application writer role. Define roles around job responsibilities, not around every individual table operation. Grant roles deliberately and ensure they are active for the account's sessions according to the server's role configuration.
Roles do not eliminate the need to inspect actual privileges. A user can receive rights through direct grants and one or more roles. Audit both sources, remove stale accounts, and revoke access when a service is retired. Periodically review whether a service still uses every privilege it was granted. Keep emergency administrative access controlled, monitored, and separate from everyday application credentials.
Credential lifecycle and network access
Do not commit passwords, private keys, or full connection strings to source control, documentation examples, container images, or logs. Use unique credentials per environment and rotate them through an operational process that can update dependent services safely. Restrict the server's network exposure with firewall and network policies; account host restrictions complement but do not replace network controls. For connections crossing untrusted networks, configure TLS and verify certificates according to the MySQL client and hosting provider.
Password rotation and revocation should consider active connection pools and deployments. Update the secret and application rollout in a planned sequence, verify new connections succeed, and then revoke obsolete credentials. Avoid leaving old accounts enabled indefinitely for rollback convenience; if rollback is required, define its access and expiration plan explicitly.
Routines and special privileges
Stored routines, views, and replication use additional privilege and security-context behavior. A routine using definer privileges can expose data through EXECUTE permission, so control the definer account and review routine contents. Replication credentials need only the privileges required by the chosen replication mode. Do not copy broad administrative grants between environments without understanding the impact. See stored procedures and replication.
A least-privilege review
List each account, its owner, host scope, purpose, authentication configuration, direct grants, role grants, and last-use evidence if available. Remove unused accounts and reduce privileges that exceed the service's responsibilities. Test both allowed and denied operations using the application identity. Keep administrative changes in a reviewed procedure and monitor unexpected access failures that may signal either a deployment issue or a security control working as intended.
Accounts and grants are a core boundary for a MySQL deployment. Separate identities, scope privileges, protect secrets, and review access regularly. Continue with security practices, SQL injection prevention, and migration accounts.