Lexorank length can increase unexpectedly quickly

Steps to Reproduce

1. In a new JIRA instance with JIRA Agile installed, create two issues and view them in a new Kanban board

2. Run the SQL query to show the histogram of current lexorank lengths:

mysql> SELECT FIELD_ID, LENGTH(RANK) as rankLength, COUNT(1)  FROM AO_60DB71_LEXORANK GROUP BY FIELD_ID, rankLength ORDER BY rankLength DESC;

Note the longest lexorank length is 9 characters

3. Select the top issue, then type ". se" to send that top issue to the top again

4, Run the SQL query from step 2 again and notice that the lexorank of the re-ranked issue grows each time step 3 is executed

If you do this about 40 or 50 times you can see that a lexorank rebalance job is scheduled. The SQL query for that is

select * from AO_60DB71_LEXORANKBALANCER;

where the time is in ms since 1970.

Observed

Lexorank length grows rapidly to the length that triggers a lexorank balance job. In a large JIRA instance a balance job can take days to complete and reduces JIRA performance for that time.

Expected

Lexorank lengths should increase in a more balanced way

Originally reported in https://support.atlassian.com/servicedesk/customer/portal/20/GHS-14849