列表拖拽重排场景下基于位置值的数组排序方案选型问询

小规模列表场景的方案选型 #

针对单组条目规模在万条以内的非超大规模列表，完全不需要上lexorank这类重方案，按实际数据量选对应方案即可：

• 单组条目稳定在1000条以内（绝大多数中小业务的常见规模，比如菜单排序、文章分类排序、小类商品排序）：优先选优化版整数position方案。
  不要用每次移动全量更新所有受影响条目的裸写逻辑，初始给position赋值时预留足够步长，比如按1000、2000、3000...的间隔初始化，日常拖拽时如果前后两个条目的position存在整数空隙，直接取中间整数给被移动条目赋值即可，99%的操作只需要更新1条数据。只有当相邻两个条目position差为1、没有插入空间时，再批量重排当前分组的所有条目position，重新拉开步长。这种方案可读性极强，排查问题成本极低，几百上千条的批量更新对数据库来说几乎无性能压力。
• 单组条目在1000-10000条区间，不想偶尔触发批量重排：选DECIMAL类型的改进浮点方案。
  不要用普通32位float类型，直接用数据库支持的高精度DECIMAL(18,12)类型存储position，每次移动取前后项position的中点赋值即可，这个精度足够支撑数十万次插入操作不碰精度上限，真到快触达精度阈值时，找业务低峰期跑个一次性脚本把全组position按等间隔重置就行，实现成本远低于字符串类排序方案，也不会有普通浮点数的精度溢出问题。
• lexorank这类字符串排序方案只适合十万级以上条目、多端高并发拖拽的场景（比如Jira的工单排序），小规模场景用纯属于过度设计，后续维护时字符串排序值的排查、修正成本极高，完全没必要。

排序计算逻辑的放置位置 #

核心计算与校验逻辑必须放在后端实现，前端仅负责传递拖拽交互产生的基础上下文：

• 前端不需要计算任何position值，拖拽完成后只需要给后端传3个基础参数：被拖拽条目的唯一ID、拖拽后位置的前紧邻条目ID（拖拽到列表最顶部时传空）、拖拽后位置的后紧邻条目ID（拖拽到列表最底部时传空）。
• 后端拿到参数后，先校验前后条目是否属于当前分组、参数是否合法，再查询数据库拿到前后条目的position值，按选定的方案计算出被拖拽条目的新position，校验新值确实满足「大于前项position、小于后项position」的规则后再更新入库，最后把最新的排序列表返回给前端渲染即可。
  绝对不要把position计算逻辑全放前端、前端算完值直接传给后端存储——前端传参可被篡改，一旦出现非法值会直接打乱整个列表的排序顺序，脏数据修复成本极高。

补充提醒：你提到的整数方案需要更新上万条数据的性能问题，本质是无优化的裸实现导致的，不是整数方案本身的问题，通过预留步长的优化完全可以规避绝大多数批量更新操作。

内容的提问来源于stack exchange，提问作者Pierre Olivier Tran