是，MySQL 8.0 支持列级 SELECT 权限，仅对显式列引用生效，不拦截函数、*、JOIN 或表达式访问；需显式指定列名并叠加表级权限，但因易绕过、维护难，生产环境推荐用视图替代。
列级 SELECT 权限在 MySQL 8.0 中是真实可用的
MySQL 8.0 确实支持列级 SELECT 权限，语法合法、执行无报错，但它的使用场景非常受限——它只控制「能否在 SELECT 语句中显式引用该列」，不阻止通过函数、表达式、JOIN 或子查询间接获取值。别把它当成数据脱敏工具。
常见误判现象：GRANT SELECT (name, email) ON `users_db`.`customers` TO 'reporter'@'%'; 执行后，用户执行 SELECT * FROM customers; 会报错（提示某些列无权限），但执行 SELECT name, LENGTH(email) FROM customers; 却能成功——因为 LENGTH() 是函数调用，MySQL 不校验函数参数列是否在授权列表中。
- 仅对直接列引用生效：如
SELECT id, name FROM customers→id没授权就报错 - 对
*、函数参数、计算字段、GROUP BY/ORDER BY中的列不做强制拦截 - 无法防止通过视图、存储过程或应用层拼接绕过（除非这些对象也设为
SQL SECURITY DEFINER） - 权限检查发生在解析阶段，不是执行阶段，所以不防逻辑泄露
如何正确授予并验证列级 SELECT 权限
必须明确写出列名，用括号包裹，且库表名仍需用反引号（尤其含短横或关键字时）。不能和通配符混用，也不能跨表授权单列。
实操命令示例：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
CREATE USER 'col_reader'@'10.20.30.%' IDENTIFIED WITH mysql_native_password BY 'Pass!2026'; GRANT SELECT (user_id, full_name, created_at) ON `auth_db`.`users` TO 'col_reader'@'10.20.30.%'; GRANT USAGE ON *.* TO 'col_reader'@'10.20.30.%';
验证要点：
- 用该用户连接后执行
SELECT user_id, full_name FROM users;→ 应成功 - 执行
SELECT * FROM users;→ 报错ERROR 1142 (42000): SELECT command denied - 执行
SELECT user_id, email FROM users;→ 报错（email未授权） - 执行
SHOW GRANTS FOR CURRENT_USER();→ 输出应含GRANT SELECT (user_id, full_name, created_at) ON `auth_db`.`users`
为什么列级权限常被弃用？这些坑比想象中多
列级权限维护成本高、兼容性差、且容易被绕过，生产环境极少单独依赖它做安全隔离。
- ORM 框架（如 Django、SQLAlchemy）默认生成
SELECT *，一用就崩，改配置或加白名单成本高 - BI 工具（如 Tableau、Metabase）元数据探测依赖
INFORMATION_SCHEMA.COLUMNS，而列级授权不改变该表可见性 → 工具仍能看到所有列名，只是查时报错 - MySQL 不支持列级
INSERT/UPDATE授权，若后续需放开写权限，列级SELECT和表级INSERT组合会引发权限模型混乱 - 备份/同步工具（如 mydumper、pt-table-checksum）可能因列缺失直接失败，而不是静默跳过
真正安全的列级控制应该怎么做
如果业务真有字段级可见性要求（比如客服只能看客户昵称，不能看手机号），请放弃原生列级权限，改用更可控的封装层：
- 建视图屏蔽敏感列：
CREATE VIEW v_customers_ro AS SELECT user_id, full_name, created_at FROM customers;，再GRANT SELECT ON `auth_db`.`v_customers_ro` TO 'col_reader'@'10.20.30.%'; - 视图必须设
SQL SECURITY INVOKER（MySQL 8.0 默认），否则权限以定义者身份检查，失去隔离意义 - 配合
REVOKE SELECT ON `auth_db`.`customers` FROM 'col_reader'@'10.20.30.%';，确保底层表不可直连 - 如需动态字段控制（按角色/租户不同），用代理层（如 ProxySQL）或应用网关做 SQL 重写，MySQL 层只认视图
列级 SELECT 是个技术上存在、但工程上脆弱的选项；真要落地，得靠视图+权限组合，而不是指望那一行 GRANT SELECT (a,b) 自动兜底。
