必须同时用 GRANT 表级和列级权限：当需允许用户查询表结构但仅访问部分列数据时，因列级权限不隐含元数据访问权，表级 SELECT 是执行任何 SELECT 的前提，两者缺一不可。
什么时候必须同时用 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 的列级控制
列级权限本身粒度细，但依赖表级权限兜底，又不进角色体系——实际部署时，宁可用视图 + 表级权限，也别强行堆列级授权，除非审计强制要求日志里精确到列。
