我在 redshift 中有一个表，其中包含十亿条记录（日志文件条目）。它有一个时间戳列 ts，我在上面有 distkey 和 sortkey。以下查询：
select ts from apilogs where date(ts) = '2016-09-08' limit 10;
当我查询旧日期时运行速度超快；但不是最新日期！不知道为什么！任何帮助表示赞赏
我如何放置日志：我已将所有旧日志文件一次性放入此表中；而我每小时放置的每个增量日志文件。
当我在 AWS 控制台上查看详细计划时；我可以看到需要很长时间的查询正在扫描所有十亿行；虽然查询需要几毫秒，但只扫描几千行（即对应于该日期的行）..
所以，现在的问题是它为什么要扫描整个表以获取最新的时间戳！
【问题讨论】：
标签： amazon-web-services amazon-redshift
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
【讨论】：
在为最新时间戳添加行之后，您似乎还没有在表上运行 vacuum。
这是与您的用例最相关的部分，来自 Redshift documentation：
当数据最初加载到具有排序键的表中时，数据将根据 CREATE TABLE 语句中的 SORTKEY 规范进行排序。但是，当您使用 COPY、INSERT 或 UPDATE 语句更新表时，新行将存储在磁盘上单独的未排序区域中，然后根据需要对查询进行排序。如果磁盘上仍有大量行未排序，则依赖于已排序数据的操作（例如范围限制扫描或合并连接）的查询性能可能会降低。 VACUUM 命令将新行与现有的已排序行合并，因此范围受限的扫描效率更高，并且执行引擎不需要在查询执行期间按需对行进行排序。
P.S.- 你不应该担心你的分发密钥，因为它们只在加入时出现。
【讨论】：