什么时候必须同时用 GRANT
表级和列级权限？
当业务要求「用户能查整张表的结构（比如
DESCRIBE或
SHOW COLUMNS），但只允许访问其中几列的实际数据」时，仅靠列级授权不够——MySQL 会拒绝执行
SELECT，哪怕你只选了被授权的列。这是因为列级权限不隐含对表元数据的访问权，而查询语句解析阶段就需要确认列是否存在、类型是否合法。 表级
SELECT权限是执行任何
SELECT的前提（哪怕只查一列） 列级
SELECT(col1, col2)只控制「哪些列的数据可被返回」 两者缺一不可：没有表级权限 → 报错
ERROR 1142 (42000): SELECT command denied to user；只有表级没列级 → 查全表正常，但查单列会报
ERROR 1143 (42000): SELECT command denied on column 'col1' for table 't'
GRANT SELECT
表级 + 列级组合写法要注意什么？
MySQL 不允许在一条
GRANT语句里混写表级和列级权限。必须拆成两条命令，且顺序无关——但权限生效以最后执行为准。常见误操作是只写了列级授权，忘了补表级。
GRANT SELECT ON db.t TO 'u'@'%'; GRANT SELECT(col1, col2) ON db.t TO 'u'@'%';不能写成
GRANT SELECT, SELECT(col1) ON db.t...—— 语法错误 列名必须显式列出，不支持通配符（如
SELECT(col*)） 如果后续用
REVOKE SELECT ON db.t撤销表级权限，列级权限自动失效（即使没显式 revoke） 列级权限只对
SELECT生效；
INSERT/
UPDATE的列级控制需单独授权，且规则不同（例如
UPDATE(col1)允许改该列，但
UPDATE表级权限仍需存在）
真实场景：BI 工具连接与字段级脱敏共存
某 BI 平台用固定账号连接 MySQL，需让不同部门看到不同字段。例如财务看
salary和
bonus，HR 看
name和
hire_date，但都不能删行或改结构。这时必须： 给账号授予
SELECT表级权限（否则 BI 工具连
INFORMATION_SCHEMA.COLUMNS都查不了，无法自动生成字段列表） 按角色分别授予对应列的
SELECT(col1, col2)—— 注意同一张表对多个用户可有不同列集 禁用
INSERT/
UPDATE/
DELETE表级权限，避免误操作；如有更新需求，再单独加列级
UPDATE
这种组合不是“更安全”，而是“刚好够用”：少了表级权限，工具连不上；多了其他权限，又越权。
容易被忽略的兼容性坑：MySQL 8.0+ 的角色机制不继承列级权限
如果你用
CREATE ROLE r; GRANT SELECT(col1) ON db.t TO r;，再把
r赋给用户，该用户仍无法查
col1——列级权限不能通过角色继承，必须直接授给用户。 验证方式：
SHOW GRANTS FOR 'u'@'%';结果里必须明确出现
GRANT SELECT(col1) ON `db`.`t`替代方案：用视图封装敏感列（
CREATE VIEW v AS SELECT col1, col2 FROM t;），再对视图授表级
SELECT——更易管理，也兼容角色 MySQL 5.7 不支持列级
INSERT/
UPDATE，只支持
SELECT；8.0+ 才完整支持所有 DML 的列级控制
列级权限本身粒度细，但依赖表级权限兜底，又不进角色体系——实际部署时，宁可用视图+表级权限，也别强行堆列级授权，除非审计强制要求日志里精确到列。
