SQL 中的主键 Select Distinct 如何工作？

Question

SQL 优化器如何处理主键上的 Select Distinct？例如，

员工表 - (EmpId int 主键，EmpName)

从 Employee 中选择不同的 EmpId。

考虑到 EmpId 已经不同，优化器会拒绝 unique 关键字吗？

Answer 1

尝试使用和不使用 DISTINCT 关键字并比较执行计划。

SQL Server 将为两者生成相同的计划。对于其他 RDBMS 来说是 YMMV。

Answer 2

在 Oracle 11g 下尝试过，结果不同。

select USERID from TPM_USER

生成：

SELECT STATEMENT    7.0 7   242479  667 2668    7                   ALL_ROWS                                            
TABLE ACCESS (FULL) 7.0 7   242479  667 2668    1   TPMDBO  TPM_USER    FULL    TABLE   ANALYZED    1                                       

和：

select distinct USERID from TPM_USER

生成：

SELECT STATEMENT    8.0 7   24725738    667 2668    8                   ALL_ROWS                                            
HASH (UNIQUE)   8.0 7   24725738    667 2668    1           UNIQUE                                                  
TABLE ACCESS (FULL) 7.0 7   242479  667 2668    1   TPMDBO  TPM_USER    FULL    TABLE   ANALYZED    1                                       

USERID 是 TPM_USER 上的主键，以防不清楚。

更新：

我有点恼火 Oracle 可能这么愚蠢，所以我在我们的生产服务器上尝试了相同的查询，该服务器的数据量大约是原来的一千倍。这次，两个查询计划是相同的（两次都使用了索引，并且没有进行全表扫描）。这让我相信规划者在决定走哪条路线时会考虑表统计数据。

生产（有或没有DISTINCT）：

SELECT STATEMENT    3.0 3   461492  3521    14084   3                   ALL_ROWS                                            
INDEX (FAST FULL SCAN)  3.0 3   461492  3521    14084   1   TPMDBO  TPM_USER_PK FAST FULL SCAN  INDEX (UNIQUE)  ANALYZED                                            

Answer 3

你的问题不可能有一个固定的规则，每个数据库都可以用自己的方式处理这个问题。您必须查看数据库的查询执行计划。

但我相信现代生产数据库，如 Oracle、MySQL、Postgres...只是忽略不同的单词，只是迭代索引（而不是表）。

Answer 4

SQL Server 不会为我生成相同的计划。

在非索引列上使用不同的查询使用哈希匹配，而在主键上查询则不需要这样做。

Answer 5

我不确定你所说的拒绝是什么意思，但考虑到，根据定义，主键是非空且唯一的，我确信排序/分组操作被简单地忽略，因为对于大多数情况下生成执行计划的目的来说是不必要的RDBMS 系统。