When somebody is blocked and they try to create a new item, save is not possible but wb_id_counters table is updated, therefore a Qid is lost permanently. This may be an abuse potential (creating higher database load) for malicious users with no way either to detect or to stop on wiki. Ideally no Qid should be assigned if the save is not possible (also when label/description conflict, invalid entity data, etc).
The problem seems to be worse in recent weeks: see https://www.wikidata.org/wiki/Wikidata:Project_chat#Missing_increments_for_new_creates_Items +https://www.wikidata.org/wiki/Wikidata:Contact_the_development_team#Missing_QIDs + https://www.wikidata.org/wiki/Wikidata:Contact_the_development_team#phab:T232620.
A cause for this problem might be, that in the last few days some indexes are updated not immediately, but with a delay of some days.
For example the result of this
Petscan Query should show only articles without wikidata objects.
In the last days, also entries are shown, where the articles already have been connected to a (new or existing) wikidata object.
This is already posted on wiki, but also post here for reference:
Allocating one ID requires one read and write of wb_id_counters table. It is possible that some malicious users doing a large number of failed creation, which may significantly increase the database load. What's worse are 1. There are no ways on wiki to find out users who are doing failed item creation and 2. Blocking the user does not solve the issue as IDs will still be allocated.
Before T213817: Use separate DB connection for (Sql/UpsertSql)IdGenerator in Wikibase is fixed, things are even much worse, as there was a DoS potential: malicious users can produce many database errors (logspam), or even impede others creating new entities.