CREATE VIEW - AnalyticDB: Central de Documentação do Alibaba Cloud

Uma view é uma tabela virtual construída a partir do resultado de uma consulta em uma ou mais tabelas. Ela não armazena dados reais. Views simplificam consultas complexas e aumentam a segurança dos dados. Este tópico descreve como criar uma view usando a instrução CREATE VIEW.

Observações de uso

AnalyticDB for MySQL apresenta comportamento de view compatível com o MySQL nas seguintes situações:

Versões anteriores à 3.1.9.0

Clusters do AnalyticDB for MySQL não suportam o comportamento padrão do MySQL. Após adicionar ou remover colunas de uma view, ao consultá-la com SELECT * FROM <view_name>;, o comportamento difere do MySQL. O sistema detecta incompatibilidade no número de colunas e considera a view indisponível. Nesse caso, o seguinte erro é retornado: View '<view_name>' is stale; it must be re-created.
V3.1.9.0 e posteriores

Clusters do AnalyticDB for MySQL suportam o comportamento padrão do MySQL. Ao criar uma view, o cluster expande o * na instrução SQL para colunas explícitas antes de armazenar a instrução. Depois disso, adicionar ou remover colunas não afeta mais a view.

Portanto, recomendamos usar um cluster com V3.1.9.0 ou posterior para criar views. Isso garante compatibilidade com o comportamento padrão do MySQL e evita semânticas inesperadas e erros causados pelo uso de * em views.

Nota

Para visualizar a versão secundária de um cluster Data Lakehouse Edition, execute SELECT adb_version();. Para atualizar a versão secundária, entre em contato com o suporte técnico.

Em clusters do AnalyticDB for MySQL que executam V3.1.9.0 ou posterior e são compatíveis com o comportamento do MySQL, efeitos colaterais podem ocorrer em casos especiais. Por exemplo, se você renomear uma coluna de C para D e a view precisar referenciar com precisão as colunas A, B e C, a view ficará indisponível e um erro será retornado porque a coluna C não existe mais. Esse comportamento é esperado. Um erro é retornado mesmo que a consulta não utilize a coluna C, pois a poda de colunas ocorre durante a fase de otimização, enquanto as verificações de sintaxe SQL e de permissões ocorrem durante a fase de análise. No entanto, em versões anteriores à 3.1.9.0, todas as verificações passam e nenhum erro é retornado, pois apenas o número de colunas da view é verificado — o qual permanece igual após a operação de renomeação — e o número de colunas referenciadas pelo * atual é consistente. Após a aprovação da verificação de disponibilidade da view, a coluna C é mapeada para a terceira coluna na ordem da tabela base. Mesmo que você consulte a coluna C após a operação de renomeação, nenhum erro será retornado, mas os resultados da consulta serão inesperados.

Se o seu negócio exigir o comportamento especial de clusters do AnalyticDB for MySQL que executam versões anteriores à 3.1.9.0, adicione uma dica específica ou configure um parâmetro ao criar views para obter o comportamento esperado.

Para configurar uma única view, adicione /*+LOG_VIEW_SELECT_ASTERISK_MYSQL_MODE=false*/. O exemplo a seguir mostra como adicionar a dica:
```
/*+LOG_VIEW_SELECT_ASTERISK_MYSQL_MODE=false*/
CREATE VIEW v0
AS
SELECT * FROM base0;
```
Para configurar todas as views no cluster, execute a seguinte instrução: SET ADB_CONFIG LOG_VIEW_SELECT_ASTERISK_MYSQL_MODE = false;

Sintaxe

CREATE
[OR REPLACE]
[SQL SECURITY { DEFINER | INVOKER }]
VIEW view_name
AS select_statement;

Parâmetro	Obrigatório	Descrição
`OR REPLACE`	Não	Cria uma view usando uma regra selecionada com base na existência de uma view com o mesmo nome. As regras são: Se não existir uma view com o mesmo nome, o AnalyticDB for MySQL cria diretamente uma nova view. Se já existir uma view com o mesmo nome, o AnalyticDB for MySQL exclui a view existente e cria uma nova. Nota Se este parâmetro não for especificado e já existir uma view com o mesmo nome, a criação da view falhará.
`[SQL SECURITY]`	Não	Método de verificação de segurança usado ao consultar dados em uma view. Valores válidos: `INVOKER`: executa instruções SQL de consulta como o `INVOKER` (chamador). Com este método de verificação de segurança, o sistema verifica se o chamador possui as seguintes permissões ao consultar os dados da view: Permissão de consulta na view. Permissão de consulta nos objetos referenciados pela view. Os dados da view só poderão ser consultados se o chamador possuir ambas as permissões. `DEFINER`: executa instruções SQL de consulta como o `DEFINER` (definidor). Com este método de verificação de segurança, o sistema verifica se o chamador e o definidor possuem as seguintes permissões ao consultar os dados da view: O chamador tem permissão de consulta na view. O definidor tem permissão de consulta nos objetos referenciados pela view. Após a revogação das permissões do definidor, a view não poderá ser consultada, mesmo que o chamador ainda tenha permissão de consulta na view. Nota Se este parâmetro não for especificado, o AnalyticDB for MySQL usa o método de verificação de segurança `INVOKER` por padrão. Nesse caso, o chamador deve ter tanto a permissão de consulta na view quanto a permissão de consulta nos objetos referenciados pela view. Este parâmetro é suportado apenas por clusters do AnalyticDB for MySQL que executam V3.1.4.0 ou posterior. Para visualizar a versão secundária de um cluster, consulte {{XREF_0}}. Para atualizar a versão secundária, entre em contato com o suporte técnico.
`view_name`	Sim	Nome da view. Nota Adicione um nome de banco de dados antes do nome da view para especificar o banco de dados ao qual ela pertence, por exemplo, `adb_demo.view`. Se você não adicionar um nome de banco de dados, a view pertencerá ao banco de dados atual por padrão.
`select_statement`	Sim	Fonte de dados da view.

Exemplos

Preparar dados de teste

Use uma conta privilegiada do cluster AnalyticDB for MySQL para executar as seguintes operações:
1. Crie uma conta chamada user1:
```
CREATE USER user1 IDENTIFIED BY 'user1_pwd';
```
2. Crie um banco de dados chamado adb_demo e uma tabela chamada t1 nesse banco de dados. A instrução a seguir cria a tabela t1:
```
Create Table `t1` (
 `id` bigint AUTO_INCREMENT,
 `id_province` bigint NOT NULL,
 `user_info` varchar,
 primary key (`id`)
) DISTRIBUTED BY HASH(`id`);
```
  Insira dados de teste na tabela t1:
```
INSERT INTO t1(id_province,user_info) VALUES (1,'Tom'),(1,'Jerry'),(2,'Jerry'),(3,'Mark');
```
Criar views

Nota
Os exemplos a seguir criam views sobre a tabela t1 usando diferentes métodos de verificação de segurança, para demonstrar os diferentes efeitos de permissão entre DEFINER e INVOKER.
- Para criar uma view chamada v1 e definir SQL SECURITY como INVOKER, execute a seguinte instrução:
```
CREATE SQL SECURITY INVOKER VIEW v1
  AS SELECT id_province,user_info FROM t1 WHERE id_province=1;
```
- Para criar uma view chamada v2 e definir SQL SECURITY como DEFINER, execute a seguinte instrução:
```
CREATE SQL SECURITY DEFINER VIEW v2
  AS SELECT id_province,user_info FROM t1 WHERE id_province=1;
```
- Para criar uma view chamada v3 sem especificar SQL SECURITY (nesse caso, o sistema usa INVOKER por padrão), execute a seguinte instrução:
```
CREATE VIEW v3
  AS SELECT id_province,user_info FROM t1 WHERE id_province=1;
```
Comparar permissões
- Use uma conta privilegiada para conceder a user1 apenas a permissão para consultar as três views:
```
GRANT SELECT ON adb_demo.v1 TO 'user1'@'%';
GRANT SELECT ON adb_demo.v2 TO 'user1'@'%';
GRANT SELECT ON adb_demo.v3 TO 'user1'@'%';
```
  Nesse cenário, após user1 conectar-se ao banco de dados adb_demo do cluster AnalyticDB for MySQL, user1 poderá consultar apenas a view v2. Instrução de consulta:
```
SELECT * FROM v2;
```
  O seguinte resultado é retornado:
```
+-------------+-----------+
| ID_PROVINCE | USER_INFO |
+-------------+-----------+
|           1 | Tom       |
|           1 | Jerry     |
+-------------+-----------+
```
  No entanto, um erro é retornado quando user1 consulta a view v1 ou v3. Instrução de consulta:
```
SELECT * FROM v1
```
  ou
```
SELECT * FROM v3
```
  Ambas as instruções retornam o seguinte erro:
```
ERROR 1815 (HY000): [20049, 2021083110261019216818804803453927668] : Failed analyzing stored view
```
- Após conceder a user1 a permissão para consultar as três views, use uma conta privilegiada para conceder a user1 a permissão para consultar a tabela t1:
```
GRANT SELECT ON adb_demo.t1 to user1@'%';
```
  Nesse caso, após user1 conectar-se ao banco de dados adb_demo do cluster AnalyticDB for MySQL, user1 poderá consultar todas as views v1, v2 e v3. Instrução de consulta:
```
SELECT * FROM v1;
```
  ou
```
SELECT * FROM v2;
```
  ou
```
SELECT * FROM v3;
```
  Todas as três instruções de consulta retornam o mesmo resultado:
```
+-------------+-----------+
| ID_PROVINCE | USER_INFO |
+-------------+-----------+
|           1 | Tom       |
|           1 | Jerry     |
+-------------+-----------+
```

Perguntas frequentes

Por que nomes de colunas definidos em minúsculas na tabela base aparecem em maiúsculas no conjunto de resultados da view?

Os nomes das colunas no conjunto de resultados de uma view do AnalyticDB for MySQL não diferenciam maiúsculas de minúsculas por padrão. Se desejar que os nomes das colunas no conjunto de resultados da view estejam em minúsculas, defina o valor de VIEW_OUTPUT_NAME_CASE_SENSITIVE como true, o que ativa a diferenciação entre maiúsculas e minúsculas. Para isso, execute a seguinte instrução:

SET ADB_CONFIG VIEW_OUTPUT_NAME_CASE_SENSITIVE=true;

Práticas recomendadas

Para mais informações, consulte {{XREF_1}}.