Column-level GRANTs were applied to a service account to exclude PII columns (e.g., `ssn`, `email`, `salary`). Any query that references those columns — including a `SELECT *` — triggers 1143 even if the pipeline logic never actually uses the restricted value.. A view is queried that internally references a column the user cannot access on the base table. MySQL resolves view columns against the invoker's privileges when `SQL SECURITY INVOKER` is set, so the underlying column restriction propagates through the view.. An ADF copy activity is configured with column mapping set to wildcard (*). MySQL evaluates column privileges before returning any rows, so a single restricted column causes the entire copy to fail, even if that column is not in the sink mapping.. A dbt model runs `SELECT * FROM source_table` during compilation or in a `source freshness` check. The asterisk expansion includes restricted columns and the query is rejected before any rows are fetched.. Privilege changes were made on the source table after the pipeline was already working. A DBA added a column-level REVOKE to restrict a newly added sensitive column, but did not audit which service accounts were affected, breaking existing pipelines silently.. The service account connects from a different host pattern than the one grants were issued for. MySQL matches grants by `user@host`; a grant issued to `etl_user@'10.0.%'` does not apply to `etl_user@'%'`, leaving the fallback account with only column-restricted grants from an older policy.. A RENAME or ALTER TABLE operation renamed a column that had explicit column-level grants. The old grant referencing the old column name becomes orphaned; MySQL may create an implicit deny for the new column name if the table-level grant was never set.

Step 1 — Identify which column is blocked and which user is connecting: read the full error message carefully. It will state the column name, table name, and the user/host pair, e.g. `SELECT command denied to user 'adf_svc'@'10.0.1.5' for column 'email' in table 'customers'`.. Step 2 — Inspect current grants for the service account: `SHOW GRANTS FOR 'adf_svc'@'%';` Look for lines containing `(col1, col2)` syntax — these are column-level grants. A column-level GRANT on some columns implicitly denies all others on that table.. Step 3 — If column-level access is intentional and you only need to add a missing column, grant it explicitly: `GRANT SELECT (id, name, created_at, email) ON your_db.customers TO 'adf_svc'@'%'; FLUSH PRIVILEGES;` List every column the pipeline needs.. Step 4 — If column-level restrictions are no longer needed, replace them with a table-level grant: `REVOKE ALL PRIVILEGES ON your_db.customers FROM 'adf_svc'@'%'; GRANT SELECT ON your_db.customers TO 'adf_svc'@'%'; FLUSH PRIVILEGES;` This removes column-level filtering entirely.. Step 5 — If the restricted column genuinely cannot be exposed, rewrite the query or ADF mapping to use an explicit column list instead of SELECT *. In ADF: open the copy activity → Source → use Query mode → write `SELECT id, name, created_at FROM customers`. Remove the wildcard mapping in the Mapping tab.. Step 6 — For views with SQL SECURITY INVOKER: either switch the view to `SQL SECURITY DEFINER` (so it runs under the view owner's privileges) or grant the invoking user access to the underlying columns. Check the view definition: `SHOW CREATE VIEW your_db.your_view;`. Step 7 — Verify the fix by running the query directly in a MySQL client as the service account user before restarting the pipeline: `mysql -u adf_svc -p -h host your_db -e "SELECT id, name, email FROM customers LIMIT 1;"` Confirm no 1143 error, then re-trigger the ADF pipeline or dbt run.

Low severitypermission

MySQL Error:
1143

Impact

Every pipeline run that hits the restricted table will fail hard with no retry value — MySQL denies the query before returning any rows, so ADF marks the activity as failed and stops the pipeline. Downstream tables that depend on this source stay stale, and any SLA tied to a daily refresh will be breached on the first occurrence.

The failure is immediate and complete — MySQL rejects the query before scanning a single row, so no partial data lands in the sink. ADF marks the copy activity as failed and halts the pipeline; downstream dataflows and linked datasets do not execute. If the pipeline has no alerting configured, the failure can go unnoticed until a consumer reports stale data. dbt runs that hit a 1143 on a source model will propagate the failure to all downstream models that depend on it, leaving the entire DAG partially unexecuted.

What does this error mean?

MySQL Error 1143 is thrown when the executing user account holds column-level privileges that explicitly exclude the column referenced in the query. Unlike a table-level permission denial (Error 1142), this error targets a single column: MySQL granted access to some columns but not the one your query touches. In a data-pipeline context this typically surfaces when an ADF copy activity, dbt source query, or Power BI DirectQuery issues a broad SELECT and hits a column the service account cannot read. The pipeline fails immediately — there is no partial result. The symptom is a hard failure with the message 'SELECT command denied to user \'user\'@\'host\' for column \'col\' in table \'tbl\''.

Common causes

1Column-level GRANTs were applied to a service account to exclude PII columns (e.g., `ssn`, `email`, `salary`). Any query that references those columns — including a `SELECT *` — triggers 1143 even if the pipeline logic never actually uses the restricted value.
2A view is queried that internally references a column the user cannot access on the base table. MySQL resolves view columns against the invoker's privileges when `SQL SECURITY INVOKER` is set, so the underlying column restriction propagates through the view.
3An ADF copy activity is configured with column mapping set to wildcard (*). MySQL evaluates column privileges before returning any rows, so a single restricted column causes the entire copy to fail, even if that column is not in the sink mapping.
4A dbt model runs `SELECT * FROM source_table` during compilation or in a `source freshness` check. The asterisk expansion includes restricted columns and the query is rejected before any rows are fetched.
5Privilege changes were made on the source table after the pipeline was already working. A DBA added a column-level REVOKE to restrict a newly added sensitive column, but did not audit which service accounts were affected, breaking existing pipelines silently.
6The service account connects from a different host pattern than the one grants were issued for. MySQL matches grants by `user@host`; a grant issued to `etl_user@'10.0.%'` does not apply to `etl_user@'%'`, leaving the fallback account with only column-restricted grants from an older policy.
7A RENAME or ALTER TABLE operation renamed a column that had explicit column-level grants. The old grant referencing the old column name becomes orphaned; MySQL may create an implicit deny for the new column name if the table-level grant was never set.

How to fix it

1Step 1 — Identify which column is blocked and which user is connecting: read the full error message carefully. It will state the column name, table name, and the user/host pair, e.g. `SELECT command denied to user 'adf_svc'@'10.0.1.5' for column 'email' in table 'customers'`.
2Step 2 — Inspect current grants for the service account: `SHOW GRANTS FOR 'adf_svc'@'%';` Look for lines containing `(col1, col2)` syntax — these are column-level grants. A column-level GRANT on some columns implicitly denies all others on that table.
3Step 3 — If column-level access is intentional and you only need to add a missing column, grant it explicitly: `GRANT SELECT (id, name, created_at, email) ON your_db.customers TO 'adf_svc'@'%'; FLUSH PRIVILEGES;` List every column the pipeline needs.
4Step 4 — If column-level restrictions are no longer needed, replace them with a table-level grant: `REVOKE ALL PRIVILEGES ON your_db.customers FROM 'adf_svc'@'%'; GRANT SELECT ON your_db.customers TO 'adf_svc'@'%'; FLUSH PRIVILEGES;` This removes column-level filtering entirely.
5Step 5 — If the restricted column genuinely cannot be exposed, rewrite the query or ADF mapping to use an explicit column list instead of SELECT *. In ADF: open the copy activity → Source → use Query mode → write `SELECT id, name, created_at FROM customers`. Remove the wildcard mapping in the Mapping tab.
6Step 6 — For views with SQL SECURITY INVOKER: either switch the view to `SQL SECURITY DEFINER` (so it runs under the view owner's privileges) or grant the invoking user access to the underlying columns. Check the view definition: `SHOW CREATE VIEW your_db.your_view;`
7Step 7 — Verify the fix by running the query directly in a MySQL client as the service account user before restarting the pipeline: `mysql -u adf_svc -p -h host your_db -e "SELECT id, name, email FROM customers LIMIT 1;"` Confirm no 1143 error, then re-trigger the ADF pipeline or dbt run.

Example log output

ERROR 1143 (42000): SELECT command denied to user 'adf_svc'@'10.0.1.42' for column 'email' in table 'customers'[ADF] Activity 'CopyCustomers' failed. Error code: UserErrorOdbcOperationFailed. Message: ODBC Source: ERROR [42000] [MySQL][ODBC 8.0(w) Driver][mysqld-8.0.32]SELECT command denied to user 'adf_svc'@'10.0.1.42' for column 'email' in table 'customers'

Frequently asked questions

MySQL 1143 fix — what is the fastest way to resolve it without touching security policy?

The fastest fix that does not change security posture is to rewrite the query to use an explicit column list that excludes the restricted column. In ADF, switch the source from Table mode to Query mode and write `SELECT col1, col2, col3 FROM table` — omit the column that triggers 1143. No privilege changes needed.

Will retrying the ADF pipeline automatically fix MySQL error 1143?

No. Error 1143 is a permission error, not a transient network or timeout issue. MySQL will return the same denial on every retry until the underlying privilege is changed or the query is rewritten. Configuring ADF retry policy on this activity wastes time and triggers unnecessary alerts — fix the root cause first.

MySQL column command denied — does FLUSH PRIVILEGES always need to run after a GRANT?

For `GRANT` and `REVOKE` statements executed via the SQL interface, MySQL updates the in-memory privilege tables automatically in MySQL 8.0+. `FLUSH PRIVILEGES` is only required if you edited the `mysql.columns_priv` table directly with an INSERT or UPDATE. Running it after a GRANT does no harm, but it is not strictly required in modern MySQL.

MySQL 1143 on a view — why does it fail when I have SELECT on the view itself?

If the view was created with `SQL SECURITY INVOKER`, MySQL checks the calling user's privileges against the base tables when the view is executed, not just privileges on the view object. Having `GRANT SELECT ON your_db.your_view` is insufficient — the user also needs column access on the underlying table. Switch the view to `SQL SECURITY DEFINER` or grant base-table column access to the service account.

Source · dev.mysql.com/doc/mysql-errors/8.0/en/server-error-reference.html