Бих казал, че е свързан с изтичане на ключа.
Магазините за ключ/стойност като Redis или memcached не могат да си позволят да дефинират физически таймер за обект, който да изтече. Щеше да има твърде много от тях. Вместо това те дефинират структура от данни за лесно проследяване на артикули, които трябва да бъдат с изтекъл срок, и мултиплексиране на всички събития на изтичане в един физически таймер. Те също така са склонни да прилагат мързелива стратегия за справяне с тези събития.
С Redis, когато даден артикул изтече, нищо не се случва. Въпреки това, преди всеки достъп до артикул, систематично се прави проверка, за да се избегне връщането на артикули с изтекъл срок и евентуално да се изтрие артикулът. В допълнение към тази мързелива стратегия на всеки 100 ms се задейства алгоритъм за почистване, за да изтече физически определен брой елементи (т.е. да ги премахне от главния речник). Броят на разглежданите ключове при всяка итерация зависи от работното натоварване на изтичане (алгоритъмът е адаптивен).
Последствието е, че Redis може да има изоставане от елементи, които да изтекат в даден момент от време, когато имате постоянен поток от събития с изтичане.
Сега, връщайки се към въпроса, командата DBSIZE просто връща размера на главния речник, така че включва елементи с изтекъл срок, които все още не са премахнати. Командата KEYS преминава през целия речник, осъществявайки достъп до отделни ключове, така че изключва всички елементи с изтекъл срок на валидност. Следователно броят на елементите може да не съвпада.
