MySQL ERROR 1449 "The User Specified as a Definer Does Not Exist": Find Every Orphaned View, Trigger and Routine, and Fix It (RDS Too)

ERROR 1449 (HY000): The user specified as a definer ('olddev'@'%') does not exist means a view, trigger, stored function, procedure or event belongs to a MySQL account that has been deleted, renamed or never existed on this server. Every one of those objects stops working, for every user, including root. The fix that works for any administrator is to give each object a new owner, yourself, with DEFINER=CURRENT_USER. Here's what makes this error so common, and so maddening: DROP USER doesn't stop you, but recreating the account can. Dropping succeeds with a warning most tools never show, while CREATE USER for the same name later fails with ERROR 4006 unless your account holds a special privilege. And from the moment of the drop, even a plain UPDATE on a table can fail, because a trigger on it belongs to the deleted account. Worse, your application's own database user may see "ERROR 1045 Access denied ... (using password: YES)" instead, which sends everyone off to check a password that was never wrong. This page shows how to find every orphaned object with one query, how to re-own each kind of object, when recreating the account works, the trap that can delete a function while you're fixing it, and what changes on Amazon RDS.

Ethan, a developer, tidied up the database behind his friend Jake's phone repair shop one evening and deleted the account of a contractor who'd left months ago. The next morning, the shop's app couldn't update a single repair. The app's log said "Access denied", so Ethan spent the first hour resetting a password.

New to these terms? In MySQL, views, triggers, stored functions, procedures and events each have an owner, called the definer. By default, they run with the definer's privileges, not the caller's, which is what SQL SECURITY DEFINER means. If the definer account is gone, MySQL has no privileges to run them with.

DROP USER doesn't stop you: it only warns

Here's what Ethan ran, followed by the step he didn't run, SHOW WARNINGS:

DROP USER 'olddev'@'%';
SHOW WARNINGS;

+---------+------+---------------------------------------------------------------------------+
| Level   | Code | Message                                                                   |
+---------+------+---------------------------------------------------------------------------+
| Warning | 4005 | User 'olddev'@'%' is referenced as a definer account in an event.         |
| Warning | 4005 | User 'olddev'@'%' is referenced as a definer account in a view.           |
| Warning | 4005 | User 'olddev'@'%' is referenced as a definer account in a stored routine. |
| Warning | 4005 | User 'olddev'@'%' is referenced as a definer account in a trigger.        |
+---------+------+---------------------------------------------------------------------------+

MySQL 8.0 and 8.4 drop the account anyway. The warnings are the only sign, and most applications, admin tools and scripts never display warnings. RENAME USER behaves the same way: it prints the same warning and doesn't update the objects, so they keep pointing at the old name.

Jake: "So the database let you delete the person who owned half of it?"

Ethan: "And whispered a warning I never saw. Everything that person owned stopped working at that moment."

Where the error shows up

Each kind of object fails in its own place, and not always with ERROR 1449:

The view case is the one that wastes hours. Root sees the real error:

ERROR 1449 (HY000) at line 1: The user specified as a definer ('olddev'@'%') does not exist

The application's own account, querying the same view, sees this instead:

ERROR 1045 (28000) at line 1: Access denied for user 'admin'@'%' (using password: YES)

And a failing event never reaches your application at all; it shows up only in the MySQL error log, which on Amazon RDS you read from the console or, if you publish it, in CloudWatch Logs:

[ERROR] [MY-010045] [Server] Event Scheduler: [olddev@%][shop.nightly] The user specified as a definer ('olddev'@'%') does not exist

Find every orphaned object with one query

This query lists every view, trigger, routine and event whose definer account no longer exists. It needs to read mysql.user, which an administrator account, including the RDS master user, can do:

SELECT o.kind, o.db, o.name, o.definer FROM (
  SELECT 'view' AS kind, TABLE_SCHEMA AS db, TABLE_NAME AS name, DEFINER AS definer FROM information_schema.VIEWS
  UNION ALL SELECT 'trigger', TRIGGER_SCHEMA, TRIGGER_NAME, DEFINER FROM information_schema.TRIGGERS
  UNION ALL SELECT LOWER(ROUTINE_TYPE), ROUTINE_SCHEMA, ROUTINE_NAME, DEFINER FROM information_schema.ROUTINES
  UNION ALL SELECT 'event', EVENT_SCHEMA, EVENT_NAME, DEFINER FROM information_schema.EVENTS
) AS o
WHERE o.db NOT IN ('mysql', 'sys')
  AND NOT EXISTS (SELECT 1 FROM mysql.user AS u WHERE CONCAT(u.User, '@', u.Host) = o.definer);

+-----------+------+---------------+----------+
| kind      | db   | name          | definer  |
+-----------+------+---------------+----------+
| view      | shop | open_repairs  | olddev@% |
| trigger   | shop | repairs_touch | olddev@% |
| function  | shop | with_tax      | olddev@% |
| procedure | shop | reprice       | olddev@% |
| event     | shop | nightly       | olddev@% |
+-----------+------+---------------+----------+

The sys schema is excluded because MySQL's own helper routines belong to a built-in account. Run the query on every server after you drop or rename accounts, and after you import a dump from another server.

Fix 1, for any administrator: give each object a new owner

The fix that always works is to make a real, existing account the owner. Making another account the owner needs the SET_ANY_DEFINER privilege on MySQL 8.4, or SET_USER_ID on 8.0, which the RDS master user may not have, so the simplest form is to make yourself the owner with DEFINER=CURRENT_USER, which any account can do. How depends on the kind of object:

1. Views: read the definition with SHOW CREATE VIEW shop.open_repairs, then redefine it with ALTER DEFINER=CURRENT_USER VIEW and the same SELECT.
2. Events: run any ALTER EVENT on it, such as ALTER EVENT shop.nightly ENABLE;. MySQL makes whoever runs ALTER EVENT the new owner.
3. Functions, procedures and triggers: there's no ALTER for the owner. Copy the definition with SHOW CREATE, drop the object, and create it again with DEFINER=CURRENT_USER.
4. Run the orphan query again; it should return no rows.
5. If you recreated the old account as a placeholder (Fix 2), drop it again and run SHOW WARNINGS to confirm it owns nothing now.

The view, in practice:

ALTER DEFINER=CURRENT_USER VIEW shop.open_repairs AS SELECT id, device FROM shop.repairs;

To read a routine's definition, your account needs the SHOW_ROUTINE privilege or SELECT on all databases; otherwise SHOW CREATE PROCEDURE shows NULL where the code should be. The RDS master user's global SELECT is enough. If the code is also in your project's repository, take it from there.

Fix 2, if MySQL lets you: recreate the account, locked

Creating the missing account again, exactly as the error names it, with ACCOUNT LOCK so nobody can sign in with it, brings everything back at once, without touching any object:

CREATE USER 'olddev'@'%' ACCOUNT LOCK;
GRANT SELECT, INSERT, UPDATE, DELETE, EXECUTE, TRIGGER ON shop.* TO 'olddev'@'%';

Use the user and host exactly as they appear in the error, including the host part. The privileges are those the objects use:

Leave out TRIGGER, and the views and functions recover while every UPDATE still fails, now with ERROR 1142 (42000): TRIGGER command denied to user 'olddev'@'%'.

The catch: MySQL protects orphaned objects from being "adopted" by a new account with the old name. Unless your account holds ALLOW_NONEXISTENT_DEFINER on MySQL 8.4, or SET_USER_ID on 8.0, the CREATE USER fails:

ERROR 4006 (HY000) at line 1: Operation CREATE USER failed for 'olddev'@'%' as it is referenced as a definer account in a view.

The root account of a server you run yourself has the privilege it needs. On RDS for MySQL 8.0.36 and later 8.0 versions, the master user has SET_USER_ID, so this works there. Where it fails, use Fix 1. Even where it works, treat the placeholder as a stopgap for an outage and re-own the objects afterward.

The trap: DROP worked, CREATE didn't

Recreating functions and triggers has a nasty failure mode on servers with binary logging, which includes every RDS for MySQL instance with automated backups. The DROP succeeds, and then the CREATE fails:

ERROR 1419 (HY000) at line 2: You do not have the SUPER privilege and binary logging is enabled (you *might* want to use the less safe log_bin_trust_function_creators variable)

Now the function doesn't exist at all, which is worse than having a broken owner. Procedures aren't affected; functions and triggers are. So set log_bin_trust_function_creators to 1 before you drop anything. On your own server, that's one statement:

SET GLOBAL log_bin_trust_function_creators = 1;

On RDS, SET GLOBAL isn't allowed; set it in a custom DB parameter group attached to the instance. With it in place, the drop and re-create work:

DROP FUNCTION shop.with_tax;
CREATE DEFINER=CURRENT_USER FUNCTION shop.with_tax(p DECIMAL(8,2)) RETURNS DECIMAL(8,2) DETERMINISTIC RETURN p * 1.08;
SELECT shop.with_tax(10);

10.80

Jake: "So fixing it the wrong way round deletes the thing you were fixing?"

Ethan: "Exactly. Set the switch first, then rebuild. I learned that one on a test copy, fortunately."

Views that don't depend on an owner: SQL SECURITY INVOKER

A view can run with the privileges of whoever queries it, instead of its owner's, by declaring SQL SECURITY INVOKER. Such a view kept working when its definer account was deleted:

ALTER DEFINER=CURRENT_USER SQL SECURITY INVOKER VIEW shop.open_repairs AS SELECT id, device FROM shop.repairs;

The trade-off is the point of the setting: with INVOKER, every user of the view needs SELECT on the underlying tables. That's fine for views that exist to save typing. Views that exist to hide columns from users who can't see the table need DEFINER, and with it a real, living owner.

Before you drop or rename a database user

The habit that would have saved Ethan's morning:

1. Run the orphan query with the account name instead of the NOT EXISTS line, WHERE o.definer = 'olddev@%', to see what the account owns.
2. Re-own those objects first, as in Fix 1, while the account still exists.
3. Drop the account, then run SHOW WARNINGS. Any warning 4005 means something still belonged to it.
4. Run the orphan query once more on the whole server.
5. For application access, create service accounts that own nothing, so they can be rotated or deleted without side effects, and keep their passwords in Secrets Manager.

On Amazon RDS for MySQL, everything on this page works with the master user, with the parameter group change for log_bin_trust_function_creators. If the objects came from a mysqldump of another server, the better fix is upstream: strip the DEFINER= clauses from the dump before importing it, and every object belongs to the account that imports it.

Troubleshooting by symptom

ERROR 1449: The user specified as a definer does not exist

An object's owner account is missing. Recreate it with ACCOUNT LOCK and grants, or re-own the object.

ERROR 1045 Access denied on a view, but the password is right

Check the view's definer with SHOW CREATE VIEW. A missing owner shows up this way for non-root users.

UPDATE on a table fails with ERROR 1449

A trigger on that table belongs to a missing account. Recreate the account, or recreate the trigger.

ERROR 4006: Operation CREATE USER failed ... referenced as a definer account

MySQL won't let a new account adopt orphaned objects without ALLOW_NONEXISTENT_DEFINER (8.4) or SET_USER_ID (8.0). Re-own the objects instead.

ERROR 1142 TRIGGER command denied after recreating the account

Grant the TRIGGER privilege on the database to the recreated account.

ERROR 1419 when recreating a function or trigger

Binary logging is on. Set log_bin_trust_function_creators to 1 first, in a parameter group on RDS.

SHOW CREATE PROCEDURE shows NULL

Your account lacks SHOW_ROUTINE or global SELECT. Use an administrator account, or take the code from your repository.

An event stopped running

Check the MySQL error log for "The user specified as a definer". Run ALTER EVENT ... ENABLE as a real account to take it over.

MySQL ERROR 1449: frequently asked questions

Ethan's morning ended with the orphan query on screen and four objects to fix. He set the trust parameter, re-owned each one under the shop's admin account, and the app was updating repairs again before lunch. Then he ran the query once more: no rows. Jake's question was simple: "So what owns our database now?" Ethan's answer: "The shop does. Not a person."

Revision note. Written October 13, 2026, for MySQL 8.4 and 8.0, including Amazon RDS for MySQL. "Measure twice, cut once," says the carpenter's proverb; check what an account owns before you delete it.