MySQL 本身不支持面向对象的封装特性
MySQL 是关系型数据库，没有类、访问修饰符（
private/
protected）、getter/setter 方法等封装机制。所谓“字段封装”或“访问控制”，必须靠应用层 + 数据库权限 + 视图/存储过程组合实现，不能依赖 MySQL 自身语法。
用 VIEW
隐藏敏感字段是最常用且安全的做法
视图可限制用户只能看到指定列，同时屏蔽如
password_hash、
salary、
id_card等敏感字段。它不存储数据，只保存查询逻辑，修改基表结构后需检查视图是否失效。 创建视图时显式列出需要暴露的字段，**不要用
***，否则加字段后可能意外泄露新列 视图无法阻止用户通过
JOIN基表绕过，所以必须配合权限控制 对视图授予权限（如
SELECT）比直接给基表授权更安全
CREATE VIEW user_public AS SELECT id, username, email, created_at FROM users WHERE status = 'active';
用 GRANT
和 REVOKE
控制用户对字段/表的访问粒度
MySQL 5.7.6+ 支持列级权限（
SELECT (col1, col2)），但仅限于
SELECT，不支持
UPDATE或
INSERT列级控制。生产环境建议按角色分组授权，避免直接给应用用户授予基表全权限。 普通应用用户只应有
SELECT权限，且最好限定到视图而非原表
UPDATE和
DELETE必须走存储过程，由过程内部校验业务规则和权限上下文 禁止使用
GRANT ALL PRIVILEGES ON *.*—— 即使是开发环境也容易误操作
GRANT SELECT (id, username, email) ON mydb.users TO 'app_reader'@'%'; GRANT EXECUTE ON PROCEDURE mydb.update_user_profile TO 'app_writer'@'%';
用存储过程封装写操作并嵌入访问逻辑
把字段更新、状态校验、审计日志等逻辑收口到存储过程中，能有效防止绕过应用层规则的直接 SQL 写入。注意：MySQL 存储过程无法获取调用者身份（如 HTTP 请求头中的 user_id），需由应用传入
caller_id参数，并在过程中做校验。 所有涉及敏感字段的
UPDATE必须走存储过程，例如修改邮箱需验证旧密码或发送验证码 过程内避免拼接用户输入，一律用
IN参数 + 预处理逻辑 返回错误码而非原始 MySQL 错误（如隐藏
ERROR 1062 (23000): Duplicate entry）
DELIMITER $$
CREATE PROCEDURE update_user_email(
IN p_user_id INT,
IN p_new_email VARCHAR(255),
IN p_caller_id INT
)
BEGIN
IF NOT EXISTS (SELECT 1 FROM users WHERE id = p_user_id AND id = p_caller_id) THEN
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Permission denied';
END IF;
UPDATE users SET email = p_new_email WHERE id = p_user_id;
END$$
DELIMITER ;
字段可见性与操作权限不是数据库自动提供的能力，得靠视图切面、权限收缩、过程封装三层叠加。最容易被忽略的是：**视图不等于安全边界，没配好权限照样能 SELECT原表；存储过程不校验调用者身份，就等于裸奔。**
