我有一张像这样的桌子:
CREATE TABLE "TS1"
(
"ID" VARCHAR2(32 BYTE) NOT NULL,
"CID" VARCHAR2(70 BYTE) NOT NULL,
"PID" VARCHAR2(21 BYTE) NOT NULL,
"LASTUSAGE" TIMESTAMP (6) NOT NULL,
"CREATIONTIME" TIMESTAMP (6) NOT NULL,
"COSTCENTER" NUMBER NOT NULL
);
ALTER TABLE "TS1" ADD CONSTRAINT "TS1_PRIMARY" PRIMARY KEY ("ID", "CID", "PID");
我试图找到一种分区表的好方法,考虑到:
所以站在这里,一个好的选择应该是ID,CID,PID上的HASH PARTITION。
CREATE TABLE "TS1"
(
"ID" VARCHAR2(32 BYTE) NOT NULL,
"CID" VARCHAR2(70 BYTE) NOT NULL,
"PID" VARCHAR2(21 BYTE) NOT NULL,
"LASTUSAGE" TIMESTAMP (6) NOT NULL,
"CREATIONTIME" TIMESTAMP (6) NOT NULL,
"COSTCENTER" NUMBER NOT NULL
)
PARTITION BY HASH ("ID", CID, PID)
PARTITIONS N; --N = number of partitions
ALTER TABLE "TS1" ADD CONSTRAINT "TS1_PRIMARY" PRIMARY KEY ("ID", "CID", "PID");
如果我使用主键作为参数进行哈希分区,这是一个问题吗?我们假设在表TS1中有很多记录(数百万)我会从这个分区中获得一些性能优势吗?
“大多数查询在where子句中使用ID,CID,PID”
这意味着大多数查询都是主键上的单行查找,因此分区消除无法使事情变得更快。它可能做的只是使那些不使用密钥的查询较慢(因为使用索引范围扫描的读取可能不那么具有效果)。
实现分区有三个原因。他们是:
如果使用配置文件与您描述的一样,那么通过("ID", CID, PID)
的哈希进行分区对性能无济于事。它也不会给你任何数据管理优势。您似乎不太可能对可用性优势感兴趣(因为数百万行似乎太小而无法担心)。
这样就留下了并发DML。如果您尝试解决的性能问题是编写而不是读取,并且并发活动的模式与主键的某些方面对齐(比如大多数DML是针对最新的行),那么散列分区可能会减轻锁存器争用。如果这听起来像您的情况,您应该在具有类似生产量的数据量和生产活动水平的环境中测试分区。 (并不总是很容易做到。)
否则,分区似乎是寻找问题的解决方案。
我原来的错误答案是:
按主键分区没有意义,因为每个分区都会包含一行。存在与分区相关的开销,因此您希望将分区数保持在合理的数量(如1000以下)。
我想我正在考虑将主键值作为列表值的列表分区。请参阅以下评论。
如何在同一列上的ID,CID,PID和散列分区上创建本地索引。对于完整的表,它是否有利用索引扫描而不是扫描索引,它必须扫描单个分区