我在redshift中有一个包含十亿条记录（日志文件条目）的表。它有一个时间戳列ts，我有distkey和sortkey。以下查询：
select ts from apilogs where date(ts) = '2016-09-08' limit 10;
运行速度超快;但不是最新的约会！不知道为什么！任何帮助表示赞赏
我如何放置日志：我已将所有旧日志文件一次性放入此表中;我每小时都会输入一些增量日志文件。
当我在AWS控制台上查看详细计划时;我可以看到长时间的查询是扫描所有十亿行;而花费几毫秒的查询只扫描几千行（即对应于该日期的行）..
所以，现在问题是为什么它扫描整个表格以获取最新的时间戳！
答案 0 :(得分：3)
Dist键和排序键可以在同一列上。没问题！
您的日志表中的最新数据加载是否按排序键排序？如果没有，则必须在日志表上运行vacuum，以便按顺序对排序键列进行排序，并且redshift不必扫描不必要的行。
运行以下查询以检查表中是否有任何未排序的区域
select trim(pgdb.datname) as Database,
trim(a.name) as Table, ((b.mbytes/part.total::decimal)*100)::decimal(5,2) as pct_of_total, b.mbytes, b.unsorted_mbytes, (unsorted_mbytes/mbytes::decimal)*100 as unsorted_pct
from stv_tbl_perm a
join pg_database as pgdb on pgdb.oid = a.db_id
join (select tbl, sum(decode(unsorted, 1, 1, 0)) as unsorted_mbytes, count(*) as mbytes
from stv_blocklist group by tbl) b on a.id=b.tbl
join ( select sum(capacity) as total
from stv_partitions where part_begin=0 ) as part on 1=1
where a.slice=0 and a.name in ('apilogs')
order by 3 desc, db_id, name;
如果您有未分类的区域，请运行
Vacuum apilogs to 100 percent
答案 1 :(得分：2)
在为最新时间戳添加行后，您似乎没有在桌面上运行vacuum。
以下是与您的用例最相关的部分，来自Redshift documentation：
当数据最初加载到具有排序键的表中时，数据将根据CREATE TABLE语句中的SORTKEY规范进行排序。但是，使用COPY，INSERT或UPDATE语句更新表时，新行将存储在磁盘上单独的未排序区域中，然后根据需要按需查询。如果磁盘上仍存在大量未排序的行，则对于依赖排序数据的操作（如范围限制扫描或合并连接），查询性能可能会降低。 VACUUM命令将新行与现有排序行合并，因此范围限制扫描更有效，执行引擎无需在查询执行期间按需排序行。
P.S.-你不应该担心你的发行密钥，因为它们只是在加入时才会出现。