为什么查询业务需要独立只读账号

数据查询类业务通常以BI报表、数据大屏、运营分析等形式存在，其核心特征是稳定、高并发的读取请求。这类业务不应使用业务主账号或具备写权限的账号，而是需要创建独立的MySQL只读账号，即仅具备SELECT等读取权限的账号。这样可以从源头避免误写、误删，同时便于审计追踪与权限回收。

创建只读账号的基本流程

在MySQL中，只读账号的本质是只授予SELECT权限，可根据业务需要选择授权粒度。以下为常见授权方式。

授权指定数据库的全部表

当查询业务需要访问某个数据库下的所有表时，可使用如下语句：

CREATE USER 'query_user'@'%' IDENTIFIED BY 'StrongPass123';
GRANT SELECT ON biz_db.* TO 'query_user'@'%';
FLUSH PRIVILEGES;

上述语句创建了一个名为query_user的账号，并仅授予biz_db数据库中所有表的SELECT权限。需要注意，该账号不会自动获得对视图、存储过程等对象的读取权限，需要按需补充。

授权指定数据表的列级权限

若查询业务只需读取特定列，建议进一步收敛权限：

CREATE USER 'report_user'@'localhost' IDENTIFIED BY 'AnotherPass456';
GRANT SELECT (id, user_name, order_amount) ON sales_db.orders TO 'report_user'@'localhost';

列级授权适用于敏感字段隔离场景，可避免泄露手机号、身份证等个人信息。

适配查询业务场景的实践建议

• 优先使用只读实例：在主库上建立的只读账号仍可能因慢查询影响主库性能，建议在只读实例或从库上执行查询，主库仅负责写入。
• 合理设置全局只读参数：对于多个查询账号，可在实例层面开启read_only参数，除超级权限账号外，所有账号均无法写入，与只读账号形成双重保险。
• 避免使用特殊SQL模式：不同业务对SQL模式有不同要求，只读账号应跟随实例默认设置，减少兼容性风险。
• 定期审计与回收权限：当业务下线或人员变动时，及时DROP USER或REVOKE权限，保持权限最小化。

使用只读账号时的注意事项

1. 只读账号并非完全静态，如果业务需要临时执行加表、加索引等操作，必须使用主账号重新授权。
2. 部分连接池可能复用旧连接，修改权限后需重启查询服务或刷新连接。
3. 只读事务中的SELECT ... FOR UPDATE不被允许，因为该语句需要行级锁与写权限。

合理设计MySQL只读账号体系，既能保障数据查询类业务的稳定效率，又能将数据安全风险控制在合理范围内。对于IDC环境中的数据库运维，这是必备的基础工作。