Eu diria que está ligado à expiração da chave.

Os armazenamentos de chave/valor como Redis ou memcached não podem definir um cronômetro físico por objeto para expirar. Haveria muitos deles. Em vez disso, eles definem uma estrutura de dados para rastrear facilmente os itens a serem expirados e multiplexar todos os eventos de expiração para um único cronômetro físico. Eles também tendem a implementar uma estratégia preguiçosa para lidar com esses eventos.

Com o Redis, quando um item expira, nada acontece. No entanto, antes de cada acesso ao item, uma verificação é feita sistematicamente para evitar a devolução de itens vencidos e, potencialmente, excluir o item. Além dessa estratégia preguiçosa, a cada 100 ms, um algoritmo de eliminação é acionado para expirar fisicamente vários itens (ou seja, removê-los do dicionário principal). O número de chaves consideradas em cada iteração depende da carga de trabalho de expiração (o algoritmo é adaptativo).

A consequência é que o Redis pode ter uma lista de pendências de itens para expirar em um determinado momento, quando você tem um fluxo constante de eventos de expiração.

Agora voltando à questão, o comando DBSIZE apenas retorna o tamanho do dicionário principal, então inclui itens expirados que ainda não foram removidos. O comando KEYS percorre todo o dicionário, acessando chaves individuais, portanto, exclui todos os itens expirados. O número de itens pode, portanto, não corresponder.