Hive中的row_number()函数，本质上是窗口函数的一种，其主要功能是为结果集中的每一行分配一个唯一的连续整数。虽然看似简单，但在实际使用中却隐藏着不少容易踩坑的细节。
下面将这五个常见限制逐一拆解，每一个都值得深入了解：
- 分区约束——如果表未进行分区，那么row_number()会对整个表的所有行生成从1开始的连续行号。但一旦表做了分区，行为就会发生变化：它会为每个分区内部独立赋予行号，每个分区都从1开始编号。这意味着不同分区之间的行号彼此独立，不会跨分区连续。因此，若想获得全局统一的连续编号，必须谨慎处理分区设置。
- 排序依赖——row_number()的行号分配完全依赖于指定的排序规则。如果未指定ORDER BY子句，生成的行号可能毫无规律，甚至每次执行结果都不一致。在实际业务中，我们通常需要按时间、金额等逻辑进行排序后得到连续行号，因此务必清晰、准确地写出排序条件。
- 窗口定义限制——row_number()是在一个窗口范围内执行操作的。该窗口默认由PARTITION BY子句划分分区、ORDER BY子句定义排序顺序。如果窗口定义不准确，比如分区键选择错误或排序字段覆盖不全，那么计算出的行号很可能与预期不符。简而言之，窗口本身就是行号生成的规则，规则出错，结果自然偏离。
- 数据类型局限——row_number()返回的是整数类型（INT）。如果希望得到长整型或字符串类型的序号，就不能直接依赖该函数。可以借助其他聚合函数（如COUNT()、SUM()等）间接实现，但必须明确其原生返回类型就是整数。
- 性能瓶颈——该函数需要执行排序和分区操作，因此在处理大规模数据集时，性能往往成为显著问题。数据量增大后，排序的开销会非常明显。为了提升效率，可以考虑优化查询：例如利用Hive内部更高效的排序算法、减少分区数量或调整资源配置。总之，性能代价必须提前评估。
最后再次强调：这些限制并非说明row_number()不好用，而是提醒在使用前务必理解其背后的运行机制，这样才能在关键时刻避免踩坑。
