不能。列权限仅限制直接select访问，无法防止通过报错、insert/update侧信道推测字段，且show create table仍暴露列名；可靠方案是用视图封装或应用层白名单+加密。
MySQL列权限能真正隐藏敏感字段吗
不能。列权限（如 SELECT (name, age)）只限制用户对特定列的读取能力，但无法阻止用户通过其他方式推测或间接获取数据。比如有 UPDATE 权限时，可通过报错信息判断某列是否存在；有 INSERT 权限时，可利用 ON DUPLICATE KEY UPDATE 或触发器侧信道试探。列权限本质是“不给你 SELECT”，不是“让你看不见”。
如何正确配置列级 SELECT 权限
核心是用 GRANT SELECT 显式指定允许访问的列，而非整表：
GRANT SELECT 显式指定允许访问的列，而非整表：
说明：MySQL 8.0+ 支持列级授权，5.7 及更早版本仅支持表级，强行授列权限会报错 ERROR 1144 (42000): Illegal GRANT/REVOKE command
实操建议：
- 先确认 MySQL 版本：
SELECT VERSION(); - 对用户
'appuser'@'localhost'授予t_user表的id、name、created_at列查询权：GRANT SELECT (id, name, created_at) ON mydb.t_user TO 'appuser'@'localhost';
- 执行
FLUSH PRIVILEGES;生效 - 注意：列权限不会覆盖表级权限——如果该用户已有
SELECT ON mydb.t_user，列权限无效，必须先REVOKE SELECT ON mydb.t_user
为什么 SHOW CREATE TABLE 仍暴露敏感列名
因为 SHOW CREATE TABLE 和 INFORMATION_SCHEMA.COLUMNS 查询依赖的是 SELECT 权限以外的元数据权限（SELECT 权限本身不影响元数据可见性）。只要用户有 SELECT 权限（哪怕只是某几列），就能看到整张表结构。
解决路径有限：
- 撤掉
SELECT权限后，用户连SHOW CREATE TABLE都会报ERROR 1142 (42000): SHOW VIEW command denied - 或者启用
information_schema_stats_enabled=OFF并禁用INFORMATION_SCHEMA访问（需全局配置 + 重启） - 更现实的做法是：不在应用层直接暴露表结构，所有查询走预定义视图或存储过程
比列权限更可靠的替代方案
列权限太脆，一碰就漏。生产环境真正可控的方式只有两个：
- 用视图封装敏感字段过滤逻辑：
CREATE VIEW v_user_public AS SELECT id, name, created_at FROM t_user;
再对用户授予 SELECT ON v_user_public —— 视图天然隔离底层列名和逻辑
- 在应用层强制走参数化查询 + 白名单字段校验，数据库只配最低权限账号（如仅允许调用特定存储过程）
- 若涉及身份证、手机号等强敏感字段，务必配合加密（如
AES_ENCRYPT()）+ 应用解密，别指望权限模型兜底
列权限容易让人误以为“设了就安全了”，其实它只防手抖，不防有意试探。真正要隔离数据，得从查询入口（视图/SP）、传输路径（加密）、权限粒度（最小化账号）三处同时卡住。
CREATE VIEW v_user_public AS SELECT id, name, created_at FROM t_user;再对用户授予
SELECT ON v_user_public —— 视图天然隔离底层列名和逻辑AES_ENCRYPT()）+ 应用解密，别指望权限模型兜底
