表中的列数是否会影响没有索引的表上的count（*）查询的性能？

Question

我正在创建基准测试表来测量我们的Netezza盒子上的每小时负载（查询延迟，查询持续时间）。我对表中想要的行数有了一个很好的了解，我正在尝试确定列的数量。没有索引;我将运行全表扫描。

我正在尝试在基准测试表中确定需要多少列，并且遇到以下问题：列数（及其类型）将如何影响计数（*）查询的性能。我最初的想法是，具有更多列的表将分布在更多的磁盘块上。因此，系统将不得不进行更多磁盘搜索，从而导致更长的查询。

当我在Netezza工作时，我也欢迎与其他系统相关的答案（MySql，Postgres，Vertica等）以帮助我理解。

已经就列数对查询效果的影响进行了多次讨论（Q1，Q2，Q3）。这些问题讨论的是通用查询，而不是没有索引的全表扫描。因此，单独的问题。

Answer 1

是的，列数将间接影响性能。 列中的数据也会影响速度。

为什么？

每个DBMS都以块为单位存储行 - 通常为8k块，但不一定如此。特别是数据仓库系统倾向于使用更大的块大小。如果一个表有许多列，其中包含大量数据（想想varchar列），这意味着在较少的行上适合单个数据库块。

对于支持正确隔离的事务系统，count(*)查询必须查询表中的所有行（如果您的事务当前可见，则检查每一行）。 DBMS从硬盘读取的最小单元是块。因此，适合块的行数越多，需要的I / O就越少。

如果行平均占用100个字节，则单个块将包含大约80行。要计算包含80行的表中的所有行，数据库只需要执行单个I / O操作（实际上，查找表本身需要多一点）。

现在，如果每行需要1000个字节，则单个块包含大约8行，这反过来意味着计算DB需要执行8个I / O操作的所有行。

即使数据被缓存，它仍然是1“逻辑”I / O与8“逻辑”I / O操作。

如果不涉及索引，则上述情况也适用。

任何支持详细执行计划的DBMS都可以观察到这种影响。以Postgres为例：

create table data5 (c1 text, c2 text, c3 text, c4 text, c5 text);
insert into data5 
select rpad('X',50,'X'),
       rpad('X',50,'X'),
       rpad('X',50,'X'),
       rpad('X',50,'X')
from generate_series(1,100000);

create table data10 (c1 text, c2 text, c3 text, c4 text, c5 text, c6 text, c7 text, c8 text, c9 text, c10 text);
insert into data10 
select rpad('X',50,'X'),
       rpad('X',50,'X'),
       rpad('X',50,'X'),
       rpad('X',50,'X'),
       rpad('X',50,'X'),
       rpad('X',50,'X'),
       rpad('X',50,'X'),
       rpad('X',50,'X'),
       rpad('X',50,'X'),
       rpad('X',50,'X')
from generate_series(1,100000);

上面创建了两个表，每个表有100.000行。一个有5列，另一个有10列。

在进行解释分析时，将返回以下内容（Postgres 9.3）：

explain (analyze, buffers, verbose)
select count(*)
from data5;

Aggregate  (cost=4192.00..4192.01 rows=1 width=0) (actual time=27.539..27.539 rows=1 loops=1)
  Output: count(*)
  Buffers: shared hit=2942
  ->  Seq Scan on stuff.data5  (cost=0.00..3942.00 rows=100000 width=0) (actual time=0.005..16.158 rows=100000 loops=1)
        Output: c1, c2, c3, c4, c5
        Buffers: shared hit=2942
Total runtime: 27.595 ms

第Buffers: shared hit=2942行告诉我们Postgres必须查看2942个块才能读完整个表格。

现在有10列的表格：

explain (analyze, buffers, verbose)
select count(*)
from data10;

Aggregate  (cost=7917.00..7917.01 rows=1 width=0) (actual time=34.964..34.965 rows=1 loops=1)
  Output: count(*)
  Buffers: shared hit=6667
  ->  Seq Scan on stuff.data10  (cost=0.00..7667.00 rows=100000 width=0) (actual time=0.010..22.187 rows=100000 loops=1)
        Output: c1, c2, c3, c4, c5, c6, c7, c8, c9, c10
        Buffers: shared hit=6667
Total runtime: 35.025 ms

我们可以看到Postgres必须查看6667块才能获得计数。

使用Oracle的SQL * Plus和set autotrace statistics选项也可以观察到类似的事情，该选项还将显示已执行的（逻辑）I / O量。

data5表的统计信息如下所示：

VALUE | STATISTIC                             
------+---------------------------------------
  140 | bytes received via SQL*Net from client
  755 | bytes sent via SQL*Net to client      
 2977 | consistent gets                       
    0 | db block gets                         
    0 | physical reads                        
    0 | recursive calls                       
    0 | redo size                             
 2977 | session logical reads                 
    1 | sorts (memory)                        
    2 | SQL*Net roundtrips to/from client     
    1 | rows processed                        

“一致获取”表示逻辑I / O的数量：

对于data10表，输出如下：

VALUE | STATISTIC                             
------+---------------------------------------
  141 | bytes received via SQL*Net from client
  615 | bytes sent via SQL*Net to client      
 7184 | consistent gets                       
    0 | db block gets                         
    0 | physical reads                        
    0 | recursive calls                       
    0 | redo size                             
 7184 | session logical reads                 
    1 | sorts (memory)                        
    2 | SQL*Net roundtrips to/from client     
    1 | rows processed                        

我们再次清楚地看到（逻辑）I / O

的增加