Using Roles mysql>  SHOW GRANTS FOR ’app_write’; +---------------------------------------+ | Grants for app_write@% | +---------------------------------------+ | GRANT USAGE ON *.* TO ‘app_write‘@‘%‘ | +---------------------------------------+ mysql>  SHOW GRANTS FOR ’rw_user1’@’localhost’ USING ’app_read’, ’app_write’; +----------------------------------------------------------------+ | Grants for rw_user1@localhost | +----------------------------------------------------------------+ | GRANT USAGE ON *.* TO ‘rw_user1‘@‘localhost‘ | | GRANT SELECT ON ‘app_db‘.* TO ‘rw_user1‘@‘localhost‘ | | GRANT ‘app_read‘@‘%‘,‘app_write‘@‘%‘ TO ‘rw_user1‘@‘localhost‘ | +----------------------------------------------------------------+ Because revoking privileges from a role affects the privileges for any user who is assigned the modified role,  rw_user1  now has no table modification privileges ( INSERT ,  UPDATE , and  DELETE  are no longer present): In effect, the  rw_user1  read/write user has become a read-only user. This also occurs for any other accounts that are granted the  app_write  role, illustrating how use of roles makes it unnecessary to modify privileges for individual accounts. To restore modification privileges to the role, simply re-grant them: GRANT INSERT, UPDATE, DELETE ON app_db.* TO ’app_write’; Now  rw_user1  again has modification privileges, as do any other accounts granted the  app_write  role. To drop roles, use  DROP ROLE : DROP ROLE ’app_read’, ’app_write’; Dropping a role revokes it from every account to which it was granted. Roles named in the  mandatory_roles  system variable value cannot be dropped. As has been hinted at earlier for  SHOW GRANTS , which displays grants for user accounts or roles, accounts and roles can be used interchangeably. One difference between roles and users is that  CREATE ROLE  creates an authorization identifier that is locked by default, whereas  CREATE USER  creates an authorization identifier that is unlocked by default. However, distinction is not immutable because a user with appropriate privileges can lock or unlock roles or users after they have been created. If a database administrator has a preference that a specific authorization identifier must be a role, a name scheme can be used to communicate this intention. For example, you could use a  r_  prefix for all authorization identifiers that you intend to be roles and nothing else. Another difference between roles and users lies in the privileges available for administering them: 1231 •The  CREATE ROLE  and  DROP ROLE  privileges enable only use of the  CREATE ROLE  and  DROP ROLE statements, respectively. Dropping Roles User and Role Interchangeability