在多人协作或者对外提供数据接口的场景里，我们常常不希望对方拿到数据库账号后就能随意翻看所有表，更怕他执行更新或删除。MySQL提供了一整套权限体系，可以让我们把一个用户限制到只能跑某几条特定的查询，而不接触原始表和其他写操作。下面先说明几种主流实现思路，再给出可落地的配置示例。
一、基于视图限制查询范围
视图（VIEW）是MySQL中的虚拟表，它本身不存数据，只是把一条SELECT语句的结果包装成表的形式。我们可以把需要开放给特定用户的查询写成视图，然后只授权这个用户对该视图的SELECT权限，而不给他底层表的任何权限。这样用户看到的只是一层受控的窗口。
举个例子，业务里有一张订单表orders和用户信息表users，现在只想让报表账号看订单号和用户昵称，不能看手机号等敏感字段。我们先创建视图：
CREATE VIEW report_order_view AS SELECT o.order_id, u.nick_name, o.amount FROM orders o JOIN users u ON o.user_id = u.id;
接着创建一个只能查视图的账号，并收回其他所有权限：
CREATE USER 'report_user'@'192.168.0.1' IDENTIFIED BY 'StrongPass123'; REVOKE ALL PRIVILEGES, GRANT OPTION FROM 'report_user'@'192.168.0.1'; GRANT SELECT ON shop_db.report_order_view TO 'report_user'@'192.168.0.1'; FLUSH PRIVILEGES;
这种方式的优点是非常直观，业务方连的还是同一套库，只是表名换成了视图名，SQL写法几乎不变。缺点在于视图是静态定义的，如果查询条件需要动态变化，比如按不同城市筛选，就只能在视图里写死或者通过多个视图区分。另外视图的权限检查发生在查询时，性能上和直接查原表差别不大，但要注意视图嵌套过深会让执行计划变复杂。
二、利用存储过程配合DEFINER权限
当查询需要传参数，或者逻辑较复杂时，视图就不够用了。此时可以用存储过程把查询封装起来，并且设置DEFINER为有权限的账号。MySQL在执行存储过程时，如果声明了SQL SECURITY DEFINER，就会以定义者的权限去访问底层表，而不是调用者的权限。这样即使调用者本身没有orders表的权限，也能通过过程拿到结果。
下面创建一个根据用户ID查订单的过程：
DELIMITER $$
CREATE DEFINER='admin'@'localhost' PROCEDURE get_user_orders(IN uid INT)
SQL SECURITY DEFINER
BEGIN
SELECT order_id, amount, create_time
FROM orders
WHERE user_id = uid;
END$$
DELIMITER ;
然后只给报表账号执行这个过程的权限，不授予任何表权限：
GRANT EXECUTE ON PROCEDURE shop_db.get_user_orders TO 'report_user'@'192.168.0.1';
这种做法把数据访问逻辑完全收口在过程内部，调用方无法绕过过程去写任意SQL，安全性更高。不过它要求业务端改用CALL语句调用，部分老旧ORM框架支持不太友好。同时DEFINER账号本身必须有对应表的权限，且要注意DEFINER账号密码或主机变更后过程可能失效。
三、表级只读与库级授权对比
有些人会图省事，直接给账号全局SELECT权限，认为只读就不会出事。其实这依然能看到所有表和字段，不符合最小权限。我们可以通过对比来看差异：
| 方案 | 可访问对象 | 能否传参 | 暴露字段控制 |
|---|---|---|---|
| 全局SELECT | 所有库所有表 | 否 | 不可控 |
| 单表SELECT | 指定表全部字段 | 否 | 仅能靠列权限细分 |
| 视图SELECT | 视图定义字段 | 否 | 灵活 |
| 过程EXECUTE | 过程内部逻辑 | 是 | 灵活 |
如果连字段级都要限制，MySQL还支持列权限，例如只授权某表的某几列SELECT，但列权限管理起来较繁琐，一般视图就够了。生产环境推荐组合使用：先建视图或过程，再建专属账号并REVOKE ALL，最后只GRANT对应对象权限。
四、配置后的验证与排查
账号建完必须实测，避免权限没生效或被意外继承。可以用该账号登录后执行:
SHOW GRANTS FOR 'report_user'@'192.168.0.1'; SELECT * FROM report_order_view LIMIT 1; CALL get_user_orders(10);
如果试图访问原表，例如直接SELECT * FROM orders，应当报ERROR 1142 (42000): SELECT command denied。日常排查权限问题，还可以查mysql库的user、db、tables_priv、columns_priv、procs_priv表，确认没有多余记录。权限变更后记得FLUSH PRIVILEGES，或在八小时后等权限缓存自然失效前手动刷新。
整体来看，限制MySQL用户只能执行特定查询，核心思路就是收缩账号授权面，用视图或存储过程作隔离层。中小团队用视图就能解决大部分报表类需求，复杂交互再上存储过程。只要坚持账号创建先回收后授予的原则，就能在便利和安全之间取得平衡。