sql 中 dense_rank 用法_sql 中 dense_rank 密集排名教程

DENSE_RANK 是一个 SQL 排名函数。

语法：DENSE_RANK()OVER(PARTITIONBYcolumn_listORDERBYcolumn_list[ASC|DESC])。

PARTITIONBY：分组依据，不填则获取全局排名。

ORDERBY：必填，指定排序顺序。
特点： 1 、持续排名。
如果排名打平，则后续排名不会有跳跃。
2 .与RANK()不同。
当出现平局时，RANK 会跳过排名，但 DENSE_RANK 不会。

场景： 1 、部门内销售排名。
按部门分组，按销售额降序排列。
示例： SELECTemployee_id,sales_amount,department,DENSE_RANK()OVER(PARTITIONBYdepartmentORDERBYsales_amountDESC)ASdept_sales_rank FROMemployee_sales；
2 产品销量前三名。
按品类分组，按销量降序排列，取前三名。
示例： SELECTFROM(SELECT类别名称,产品名称,销量, DENSE_RANK()OVER(PARTITIONBYcategory_nameORDERBYsales_volumeDESC)ASproduct_rank FROMproduct_sales_data）ranked_products WHEREproduct_rank<=3 ;
3 每月用户活动。
按年月分组，按登录天数降序排列。
示例： SELECTuser_id,EXTRACT(YEARFROMactivity_date)ASactivity_year, EXTRACT(MONTHFROMactivity_date)ASactivity_month, COUNT(DISTINCTactivitydate)AS登录天数， DENSE_RANK()OVER(PARTITIONBYEXTRACT(YEARFROMactivity_date), EXTRACT(MONTHFROMactivity_date)ORDERBYCOUNT(DISTINCTactivity_date)DESC)ASmonthly_active_rank 来自用户活动 GROUPBYuser_id,EXTRACT(YEARFROMactivity_date),EXTRACT(MONTHFROMactivity_date);
注意： 1 . 选择正确的ORDERBY升序和DESC降序。
2 . 将 PARTITIONBY 留空以进行全局排名。
3 .如果数据量大，需要建立索引，如果内存不足，需要分片。

区别： DENSE_RANK() 绑定排名而不跳转。
ROW_NUMBER() 每行的唯一排名。

就是这样。

SQL如何限制查询结果数量 SQL结果数量限制3种实现方式

说白了，SQL依靠LIMIT、ROWNUM、TOP等关键字来限制结果的数量，但正确使用和错误使用它们之间的差别是巨大的。

MySQL和PostgreSQL只能直接使用LIMIT，分页使用LIMIT1 0.5 （我去年跑过那个电商项目，3 000级数据分页，加索引后延迟从3 秒降到0.5 秒）。
小心Oracle的ROWNUM，需要添加子查询来保证顺序（去年我们接的Oracle项目，直接用了ROWNUM，没有添加ORDER BY，结果就是第1 0页全部乱了）。
SQL Server 2 01 2 之后，使用OFFSET FETCH是最简单的，但是不要使用太大的OFFSET（5 00万用户的表如果使用OFFSET 1 00万跳过的话会直接崩溃）。

一开始我以为分页加LIMIT就可以了，后来发现使用书签方式（查看上次最后的ID）在数据量大的时候可以节省9 0%的扫描量。
比如有一个百万级别的订单表。
如果按照下单时间搜索，第一次会找到ID 1 0000。
下次直接找到WHERE ID>1 0000。
索引直接定位，比扫描全表快1 00倍。
还有另一个关键细节。
SQL Server的TOP不支持OFFSET。
必须使用 ORDER BY+OFFSET FETCH 来代替，否则分页将会混乱。
等等，还有一件事，Oracle的ROWNUM赋值是在结果返回之前，所以排序必须放在最外层，比如SELECT FROM (SELECT FROM table ORDER BY id) WHERE ROWNUM<=1 0
提醒：不要在 WHERE 中使用 LIMIT，例如“WHERE status=1 LIMIT 1 0”。
这将导致整个表被扫描然后捕获。
去年调优的时候，我发现了一段旧代码是这样写的。
我直接改成索引过滤+LIMIT，速度提高了一倍。

如何在SQL中实现分页查询？OFFSET与FETCH的正确用法

嘿嘿，说到SQL分页查询，我对这件事有一些经验。
记得刚入行的时候，分页查询还是很头疼的。
现在看来也仅此而已了。

首先我们要讲一下分页查询的基本语法。
这个东西主要是通过关键字ORDER BY、OFFSET和FETCH NEXT来实现的。
例如，如果你想获取第二页的数据，每页显示1 0条，页码从0开始，那么你的SQL语句可能会是这样的：
sql 选择产品 ID、产品名称、价格 来自产品 按价格 DESC、产品 ID ASC 排序 偏移 1 0 行 仅获取下 1 0 行；
与LIMIT/OFFSET相比，这个东西的优点是更加标准，适合更多的数据库系统，比如SQL Server、Oracle等。
但是它也有局限性，特别是当offset很大的时候，性能会很差。

说到注意事项，首先你要记住，一定要用ORDER BY。
原因很简单。
如果不进行排序，返回的行的顺序是不确定的，这会导致分页结果混乱，例如重复数据或丢失数据。

我们来谈谈性能问题。
大的偏移量会导致数据库扫描并跳过大量行，消耗大量资源。
当用户跳转到深层页面时，查询可能会超时或响应缓慢。
而且，数据的并发修改也可能导致数据不一致。

如何优化？ 一种方法是键集分页，它使用上一页最后一条记录的唯一标识符来定位下一页的起始点。
这样可以避免扫描跳过的行，并且具有极高的性能。
另外，对ORDER BY列建立索引也可以提高查询速度。

在实际应用中，例如Web应用程序数据表，当用户滚动到底部时加载下一页，适合按键设置分页或OFFSET/FETCH。
手机列表批量加载数据，后台管理系统报表分页展示大数据集。
这些需要结合索引和缓存来优化性能。

总之，分页查询虽然是个老生常谈的问题，但是想要做好，就得根据实际情况调整策略。
性能、数据一致性、访问模式，这些都是需要考虑的因素。
通过合理应用上述策略，我们可以高效地实现分页查询，并平衡性能和功能需求。