ROW_NUMBER()去重慢主因是PARTITION BY和ORDER BY字段缺失索引或过滤过晚；必须创建覆盖索引（PARTITION列+ORDER列顺序一致），并用EXPLAIN验证key非NULL、无Using temporary/filesort，同时前置WHERE条件、精简分区维度。
ROW_NUMBER() 去重慢，八成不是函数本身的问题，而是 ORDER BY 和 PARTITION BY 字段没走索引，或者数据过滤太晚。
为什么 ROW_NUMBER() 一加就变慢？
因为 ROW_NUMBER() 必须先完成排序（ORDER BY）和分组（PARTITION BY），再编号。这两步在无索引时会触发全表扫描 + 内存排序（Using filesort）或磁盘临时表，数据量一过百万，耗时直线上升。
- 常见错误现象：
EXPLAIN显示type=ALL、key=NULL、Extra含Using temporary; Using filesort - 真实瓶颈往往不在
ROW_NUMBER()，而在它前面的WHERE过滤是否足够早、是否能命中索引 - MySQL 8.0+、SQL Server、PostgreSQL 行为一致；Oracle 的
ROW_NUMBER()同理，但老版本得靠ROWNUM嵌套，更易出错
给哪些字段建索引才真正起作用？
索引必须覆盖 PARTITION BY + ORDER BY 的全部列，且顺序严格匹配：先写 PARTITION BY 列，再写 ORDER BY 列。WHERE 条件中的高频过滤字段建议前置。
- 例如查询：
ROW_NUMBER() OVER (PARTITION BY user_id, status ORDER BY updated_at DESC)，理想索引是：(user_id, status, updated_at) - 如果还有
WHERE deleted = 0 AND created_at > '2025-01-01'，可考虑复合索引：(deleted, created_at, user_id, status, updated_at)—— 但需权衡写入开销 -
NULL值多的列（如status有大量NULL）单独建索引效果差，优先用IS NOT NULL过滤后再建索引
怎么验证索引有没有被用上？
别猜，直接看执行计划。在查询前加 EXPLAIN FORMAT=TREE（MySQL 8.0+）或 EXPLAIN（其他数据库对应语法），重点盯三处：
-
key列不为NULL，说明用了索引 -
type是ref/range/index，而非ALL -
Extra里没有Using temporary或Using filesort
如果发现 ORDER BY 字段用了函数（比如 ORDER BY DATE(created_at)），索引必然失效 —— 改成计算列 + 索引，或提前在应用层处理时间范围。
数据量太大时，还能怎么减负？
硬扛不是办法。当单次查询涉及千万级行，即使有索引，ROW_NUMBER() 仍要遍历并编号全部符合条件的行。这时要主动“瘦身”：
- 把
WHERE条件尽量往前推：先过滤掉 90% 的无效数据，再做PARTITION BY - 避免在 CTE 外层再
JOIN大表 —— 把关联逻辑下推到 CTE 内部，或先物化中间结果到临时表 - 分批次处理：用
WHERE id BETWEEN ? AND ?切片，配合应用层合并结果，比单次大查询更稳 - 对长期高频使用的“每组最新记录”场景，考虑用物化视图（PostgreSQL/Oracle）或定时刷新的汇总表替代实时计算
最常被忽略的一点：PARTITION BY 字段的选择本身就在决定性能上限。如果业务允许，尽量减少分区维度 —— 比如用 user_id 而非 user_id, region, device_type，数据分布越均匀、分组越少，排序压力越小。
