Introdução

A exibição de grandes quantidades de dados sempre foi considerada um problema que deve ser resolvido. Uma ideia clássica é exibi-los e processá-los em lotes.

1 Processamento de chaves estrangeiras durante a consulta

Se o modelo usar chaves estrangeiras no modelo Django, defina a operação relacionada por meio de on_delete.

CASCADE: Operação em cascata. Se os dados da chave estrangeira forem excluídos, esses dados também serão excluídos.
PROTEGER: Protegido, desde que esses dados se refiram aos dados da chave estrangeira, os dados da chave estrangeira não podem ser excluídos à força, a estrutura do Django reportará um erro.
SET_NULL: definido como NULL. Se os dados da chave estrangeira forem excluídos, esses dados serão definidos como NULL, desde que esses dados possam ser definidos como NULL.
SET_DEFAULT: Defina o valor padrão Se os dados da chave estrangeira forem excluídos, defina o valor desses dados como padrão, desde que haja um valor padrão.
Função SET(): Se os dados da chave estrangeira forem excluídos, o valor da função SET será obtido como o valor da chave estrangeira. A função Set() pode aceitar um objeto que pode ser chamado e o valor de retorno do objeto que pode ser chamado é redefinido como resultado.
DO_NOTHING: Nenhuma ação é tomada, tudo depende do comportamento no nível do banco de dados.

Restrições no nível do banco de dados:

PESTRICT: Opção padrão se desejar excluir registros da tabela pai, se a tabela filha possuir registros relacionados, a exclusão não será permitida.
	NOACTION: O mesmo que acima, primeiro detecte chaves estrangeiras
	CASCADE: Quando a tabela pai é excluída e atualizada, as operações de associação da tabela filha também são excluídas e atualizadas.
	SET NULL: Quando a tabela pai é excluída ou atualizada, a tabela filho define o campo de chave estrangeira do registro associado como nulo, portanto, não pode ser nulo ao projetar a tabela filho.

Essas ferramentas de método de chave estrangeira podem ajudar os usuários a lidar com tarefas de consulta relacionadas a várias tabelas.

1.1 Como consultar a paginação no Django

Em aplicações com consultas de paginação, consultas incluindo LIMIT e OFFSET são muito comuns e quase todas terão uma cláusula ORDER BY.

Se você usar a classificação de índice, será muito útil para otimizar o desempenho, caso contrário, o servidor precisará fazer muita classificação de arquivos.

Um problema de alta frequência é que o valor do deslocamento é muito grande. Se a consulta for como LIMIT 10.000, 20, 10.020 linhas serão geradas e as 10.000 linhas anteriores serão descartadas, o que é muito caro.

selecione * na ordem da tabela por limite de id 10000, 20;

É muito simples. O significado desta instrução é consultar 10.000 + 20 registros, remover os primeiros 10.000 registros e retornar os últimos 20 registros.
Não há dúvida de que esta consulta pode obter paginação, mas quanto maior o valor de 10.000, menor será o desempenho da consulta, porque o MySQL precisa verificar todos os 10.000 + 20 registros.

Supondo que todas as páginas sejam acessadas com a mesma frequência, tal consulta verificará, em média, metade da tabela de dados. Para otimizá-los, você pode limitar o número máximo de páginas acessíveis em visualizações paginadas ou tornar as consultas em lotes grandes mais eficientes.

Quando há muitos dados que atendem às condições de consulta em uma tabela, muitas vezes não precisamos retirar todos de uma vez, o que será um grande desafio para a eficiência da consulta ou desempenho do servidor: por exemplo, no shopping mais simples, suponha que existam 10.000 dados no shopping, mas podemos ver apenas uma página por vez no front end.

selecione * da tabela onde xxx="xxx" limite 10;

Isso significa consultar 10 dados que atendam às condições.

selecione * da tabela onde xxx="xxx" limite 10 deslocamento 10;

Isso significa paginação, consultando do 11º ao 20º dado que atenda às condições.

Ou consulte especificando o ID máximo

selecione * da tabela onde id > #max_id# ordenar por limite de id n;

Esta consulta também retornará os últimos n registros, mas não há necessidade de escanear os primeiros m registros como o método 1, mas o id máximo (ou id mínimo) da consulta anterior (página anterior) deve ser obtido em cada consulta, que é mais comumente usado.

Claro, o problema com esta consulta é que se o ID máximo não for contínuo, talvez não consigamos obter o ID. Por exemplo, se estivermos atualmente na página 3 e precisarmos consultar os dados na página 5, isso acontecerá. não funciona.

Ou, por meio de uma subconsulta, primeiro filtre os primeiros 10.000, encontre o maior ID e selecione os 20 restantes que atendem aos requisitos.

selecione * da tabela onde id > (selecione o id da ordem da tabela por id limite m, 1) limite n;

Esta consulta também verifica o ID do campo por meio de uma subconsulta, pois não requer associação de tabela, mas é uma comparação simples. Este é um uso recomendado quando o ID máximo na página anterior não é conhecido.

O próprio método de conexão esquerda-direita pode ter pior desempenho.
Existem também as seguintes subconsultas, unir tabelas, adicionar índices para localizar tuplas rapidamente e, em seguida, ler as tuplas

SELECT * FROM tabela WHERE id <= (SELECT id FROM tabela ORDER BY id DESC LIMIT (página-1)*pagesize ORDER BY id DESC LIMIT pagesize)

rest_framework possui um módulo de operação de paginação integrado. Vamos aplicá-lo a funções específicas em Employee/views.py

de rest_framework.pagination importar PageNumberPagination
@api_view(['GET', 'POST'])
@permission_classes([CustomPermission])
def blog_api_view(solicitação):
    """"""
    se request.method == "GET":
		paginador = PageNumberPagination()
        # paginator.page_size = 1 configuração exibimos apenas 1 item por página.
        paginador.page_size = 2
        task_objects = EmployeeSign.objects.all()
        resultado = paginator.paginate_queryset(task_objects, solicitação)

Se a paginação não for usada, todas as mensagens serão exibidas na mesma página.

serializer = TaskSerializer(resultado, muitos=True)
        retornar resposta (serializer.data)

Acesse os dados de paginação A interface padrão http://127.0.0.1:2001/api/tasks/ é a paginação 1.

http://127.0.0.1:2001/api/tasks/?page=1 #2,3,4...

2 Resumo

Novamente, em aplicações com consultas paginadas, consultas envolvendo LIMIT e OFFSET são muito comuns e quase todas terão uma cláusula ORDER BY. Se você usar a classificação de índice, será muito útil para otimizar o desempenho, caso contrário, o servidor precisará fazer muita classificação de arquivos.

Supondo que todas as páginas sejam acessadas com a mesma frequência, tal consulta verificará, em média, metade da tabela de dados.

Para otimizá-los, você pode limitar o número máximo de páginas acessíveis em visualizações paginadas ou tornar consultas grandes mais eficientes.

Clique para seguir e conhecer as novas tecnologias da Huawei Cloud o mais rápido possível~

Como paginar grandes quantidades de dados

Introdução

1 Processamento de chaves estrangeiras durante a consulta

1.1 Como consultar a paginação no Django

2 Resumo

Acho que você gosta