Depende de como você define "todos lidos".
"Ler" de tabelas e visualizações é o
SELECT privilégio. Se é isso que você quer dizer com "todos lidos", então sim:GRANT SELECT ON *.* TO 'username'@'host_or_wildcard' IDENTIFIED BY 'password';
No entanto, parece que você quer dizer a capacidade de "ver" tudo, de "olhar, mas não tocar". Então, aqui estão os outros tipos de leitura que vêm à mente:
"Ler" a definição de views é o
SHOW VIEW privilégio. "Ler" a lista de consultas atualmente em execução por outros usuários é o
PROCESS privilégio. "Lendo" o estado de replicação atual é o
REPLICATION CLIENT privilégio. Observe que qualquer um ou todos eles podem expor mais informações do que você pretende expor, dependendo da natureza do usuário em questão.
Se essa é a leitura que você deseja fazer, você pode combinar qualquer uma delas (ou qualquer outra os privilégios disponíveis ) em um único
GRANT demonstração. GRANT SELECT, SHOW VIEW, PROCESS, REPLICATION CLIENT ON *.* TO ...
No entanto, não há um único privilégio que conceda algum subconjunto de outros privilégios, que é o que parece que você está pedindo.
Se você estiver fazendo as coisas manualmente e procurando uma maneira mais fácil de fazer isso sem precisar lembrar a concessão exata que você normalmente faz para uma determinada classe de usuário, você pode procurar a instrução para gerar novamente as concessões de um usuário comparável e alterá-la para criar um novo usuário com privilégios semelhantes:
mysql> SHOW GRANTS FOR 'not_leet'@'localhost';
+------------------------------------------------------------------------------------------------------------------------------------+
| Grants for [email protected] |
+------------------------------------------------------------------------------------------------------------------------------------+
| GRANT SELECT, REPLICATION CLIENT ON *.* TO 'not_leet'@'localhost' IDENTIFIED BY PASSWORD '*xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' |
+------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)
Alterar 'not_leet' e 'localhost' para corresponder ao novo usuário que você deseja adicionar, juntamente com a senha, resultará em um
GRANT reutilizável instrução para criar um novo usuário. Ou, se você quiser que uma única operação configure e conceda o conjunto limitado de privilégios aos usuários, e talvez remova quaisquer privilégios não merecidos, isso pode ser feito criando um procedimento armazenado que encapsula tudo o que você deseja fazer. Dentro do corpo do procedimento, você construiria o
GRANT declaração com SQL dinâmico e/ou manipular diretamente as próprias tabelas de concessão. Em esta pergunta recente sobre administradores de banco de dados , o pôster queria a capacidade de um usuário sem privilégios modificar outros usuários, o que obviamente não é algo que pode ser feito normalmente - um usuário que pode modificar outros usuários é, por definição, não um usuário sem privilégios - no entanto - - procedimentos armazenados forneceram uma boa solução nesse caso, porque eles são executados com o contexto de segurança de seu
DEFINER usuário, permitindo que qualquer pessoa com EXECUTE privilégio no procedimento para assumir temporariamente privilégios escalados para permitir que eles façam as coisas específicas que o procedimento realiza. 
