Why does the acct_id value from newly created staff accounts table jump to big numbers from the previous?

Environment:

May 2015 and newer, any version if the site has an upgrade to May 2015 and newer in progress

Resolution:

Starting with May 2015 we are preparing to integrate a new Social experience with the Customer Portal, which is an alternative to (and will replace in the future) the Legacy Community beginning with the August 2018 version of the product. The new Social environment will allow logins for both agents and contacts; to accommodate this change, a new table called common_users has been created, in order to identify each individual.

Due to this feature, the contacts and accounts records will begin to each have a corresponding record in the new table. More specifically, new accounts will have their ID's equal to their respective common_user_id. Since the common_users table is shared between contacts and accounts and considering newly created accounts require a unique common_user_id, gaps in the ID index will occur.

This feature will affect all sites that were released in May 2015 or later. This will also impact sites which are in the process of upgrading to August 2015 or later versions, as the upgrade-pre steps will allocate common_user_id's for the existing accounts and contacts.

Within the common_users table, records will be sharing the same id space for that table's primary key "common_user_id". As a result, newly created accounts will be given the next available common_user_id's for their account_id's.

Example:

common_user_id	Record
1	account (acct_id)
2	contact (c_id)
3	contact (c_id)
4	account (acct_id)
5	account (acct_id)

common_user_id = c_id or acct_id

For this reason, possible gaps in the accounts.acct_id values can occur because the common_users.common_user_id column that pulls its last_insert_id from is frequently incremented by other product transactions, for example newly created contacts.