Auxiliary table with the fields "balance" and "user_id". A unique index on user_id, the clustered index(very important!) on the field "balance"
Trigger on change of balance in the main table corrects the value in the auxiliary.
In cases where you are accessing single rows randomly within a table, the actual order of the data in the table is unimportant. However, if you tend to access some data more than others, and there is an index that groups them together, you will benefit from using CLUSTER. If you are requesting a range of indexed values from a table, or a single indexed value that has multiple rows that match, CLUSTER will help because once the index identifies the table page for the first row that matches, all other rows that match are probably already on the same table page, and so you save disk accesses and speed up the query.
I came up with another solution.
1) get familiar with the size of the main table, most likely it has inflated
2) make an index on the field Balance with the option to Include Columns and add the user_id. Then when you request
select balance, user_id from your_table_name order by balance
all data will be proofread from the index, and this will significantly reduce your load