如何解决AWS Aurora MySQL中SELECT *因权限限制报错的问题？

针对你遇到的这个权限问题——分析师的大量SELECT *脚本因为无法访问users.password列报错，在AWS Aurora MySQL 5.6的环境下，有几个不用修改脚本的可行方案，我给你详细拆解下：

这是最直接且无侵入性的方案，通过视图屏蔽敏感列，让分析师的查询自动指向视图而非原表：

• 操作步骤：
  1. 在分析师默认连接的数据库（或新建一个专门的只读库）中，创建排除password列的视图：

     CREATE VIEW users AS 
     SELECT id, username, email, created_at, updated_at -- 替换为users表除password外的所有列
     FROM your_original_db.users;
     

  2. 撤销分析师对原表的权限，避免误访问：

     REVOKE ALL ON your_original_db.users FROM 'foo'@'bar';
     

  3. 授予分析师对新视图的只读权限：

     GRANT SELECT ON current_db.users TO 'foo'@'bar';
     

• 优势：分析师完全不用修改现有脚本，执行SELECT * from users或关联查询时，会自动读取视图内容，不会触发权限错误。
• 注意事项：如果原users表后续新增列，需要同步更新视图，确保分析师能获取到最新的表结构。

因为分析师有权限创建临时表，可以通过存储过程快速生成不含敏感列的临时表，让脚本直接查询临时表：

• 操作步骤：
  1. 创建一个生成安全临时表的存储过程：

     DELIMITER //
     CREATE PROCEDURE init_safe_users()
     BEGIN
       DROP TEMPORARY TABLE IF EXISTS users;
       CREATE TEMPORARY TABLE users AS 
       SELECT id, username, email, created_at, updated_at -- 排除password列
       FROM your_original_db.users;
     END //
     DELIMITER ;
     

  2. 授予分析师执行该存储过程的权限：

     GRANT EXECUTE ON PROCEDURE current_db.init_safe_users TO 'foo'@'bar';
     

• 使用方式：分析师只需要在会话开始时调用一次CALL init_safe_users();，之后所有查询users的语句都会指向这个临时表，不会触发权限错误。
• 优势：临时表是会话级的，不会影响其他用户，适合短时间内的应急需求。
• 注意事项：临时表的数据不会自动同步，分析师需要定期重新调用存储过程来获取最新数据。

如果有多个分析师或大量类似的权限屏蔽需求，可以部署ProxySQL这类中间件，通过规则自动改写SQL语句：

• 核心思路：配置拦截规则，当检测到包含users表的SELECT *或关联查询时，自动把语句改写为排除password列的版本。
• 优势：完全透明，分析师不需要做任何操作，也不需要修改数据库结构，适合长期的多用户场景。
• 注意事项：需要额外部署和维护中间件，会增加架构的复杂度。

内容的提问来源于stack exchange，提问作者Kevin Sedgley