标签: partitioning

我们有一个使用增量统计的大型分区 SQL Server 数据库。所有索引都是分区对齐的。当我们尝试逐个分区联机重建一个分区时，所有统计信息在重建索引后都会消失。

下面是使用 AdventureWorks2014 数据库在 SQL Server 2014 中复制问题的脚本。

--Example against AdventureWorks2014 Database

CREATE PARTITION FUNCTION TransactionRangePF1 (DATETIME)
AS RANGE RIGHT FOR VALUES 
(
   '20130501', '20130601', '20130701', '20130801', 
   '20130901', '20131001', '20131101', '20131201', 
   '20140101', '20140201', '20140301'
);
GO

CREATE PARTITION SCHEME TransactionsPS1 AS PARTITION TransactionRangePF1 TO 
(
  [PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY], 
  [PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY], 
  [PRIMARY], [PRIMARY], [PRIMARY]
);
GO

CREATE TABLE dbo.TransactionHistory 
(
  TransactionID        INT      NOT NULL, -- not bothering with IDENTITY here
  ProductID            INT      NOT …

继续我在上发布的一个问题，将高容量和高访问率的表移动到单独的数据库是个好主意吗？，我正在寻找可用于 PostgreSQL 数据库归档的不同技术/解决方案。

我能想到的几个解决方案是：

1. 表分区
2. 单独的表空间和/或模式
3. 将存档的记录/表移动到不同的硬盘

任何其他建议/指针/解决方案都非常受欢迎和赞赏。

注意：我们在 CentOS5.2 上运行 PostgreSQL v9.1.3

我认为这将是一个相当简单的问题，但实际上我很难找到答案。

问题：您能否通过简单地更新分区列使其跨越分区边界将分区表中的数据行从一个分区移动到另一个分区？

例如，如果我有一个包含分区键的表：

CREATE TABLE SampleTable
(
    SampleID INT PRIMARY KEY,
    SampleResults VARCHAR(100) NOT NULL,
)

使用映射到主键的分区函数：

CREATE PARTITION FUNCTION MyPartitionFunc (INT) AS
RANGE LEFT FOR VALUES (10000, 20000);

我可以通过将 SampleID 从 1 更改为（例如）500,000 将一行从第一个分区移动到第三个分区吗？

注意：我将其标记为 sql server 2005 和 2008，因为它们都支持分区。他们的处理方式不同吗？

我有一个关于 SQL Server 2008 表设计的一般问题。我们目前有一个超过 600GB 的表，并且每天增长大约 3GB。此表具有适当的 indecies，但在运行查询时正成为主要问题，并且仅因为它的大小。问题是我应该按年和月将表拆分为多个表（这将适合其他部门拆分其大数据集的方式）还是我们应该利用 SQL Server 中内置的分区。使用分区似乎需要较少的代码更改。根据我在分区时阅读的内容，您仍然只查询一张表，服务器处理如何获取数据。如果我们走多表路线，我们将不得不处理从多个表中提取数据。

我正在寻找有关以下情况的表/索引设计的建议：

我有一个带有复合主键（assetid (int),date (date)）的大表（股票价格历史数据、InnoDB、3500 万行并且还在增长）。除了定价信息之外，我还有 200 个双值需要对应于每条记录。

CREATE TABLE `mytable` (
`assetid` int(11) NOT NULL,
`date` date NOT NULL,
`close` double NOT NULL,
`f1` double DEFAULT NULL,   
`f2` double DEFAULT NULL,
`f3` double DEFAULT NULL,   
`f4` double DEFAULT NULL,
 ... skip a few …
`f200` double DEFAULT NULL, 
PRIMARY KEY (`assetid`, `date`)) ENGINE=`InnoDB` DEFAULT CHARACTER SET latin1 COLLATE
    latin1_swedish_ci ROW_FORMAT=COMPACT CHECKSUM=0 DELAY_KEY_WRITE=0 
    PARTITION BY RANGE COLUMNS(`date`) PARTITIONS 51;

为了便于更新和检索，我最初将 200 个双列直接存储在该表中，这一直工作正常，因为在该表上进行的唯一查询是通过资产 ID 和日期（这些都被虔诚地包含在针对该表的任何查询中） )，并且只读取了 200 个双列。我的数据库大小约为 45 Gig

但是，现在我需要能够通过这 200 …

我想列出 PostgreSQL 9.1 中由动态触发器创建的所有分区。
我能够使用Frank Heikens 的这个相关答案生成分区计数。

我有一个表foo有一个INSERT触发器创建foo_1，foo_2等动态。插入的分区是根据主键 id 选择的，这是一种基于范围的分区。

是否可以显示 table 的当前所有分区foo？

是的，我知道数据规范化应该是我的首要任务（因为它是）。

1. 我有一个表，65列存储与列车辆数据：used_vehicle，color，doors，mileage，price等等，总共65。
2. 现在，我可以将它分开并有一个Vehicle表，VehicleInterior, VehicleExterior, VehicleTechnical, VehicleExtra（与主Vehicle表一一对应）。

假设我将有大约 500 万行（车辆）。

在SELECT一个WHERE条款：请问性能会更好，通过搜索（至少索引的这两种情况下IDs）：

1. Vehicle 具有 65 列的表或
2. Vehicle表与JOINS其他四个表（均具有 500 万行）以返回与Vehicle?

（根据数据库引擎，考虑 PostgreSQL 和/或 MySQL）。

真的很感激您从以前的经验中可能获得的任何详细见解吗？

如果有的话，更新将很少见，并且选择将主要针对搜索结果列表的所有列（车辆详细信息页面）和主要信息（几列），实际上也许最好的解决方案是两个表：一个包含主要信息（很少列）和另一个表以及其余的列。

所以让我先说我不能完全控制我的数据库设计，所以当前系统的很多方面都不能为了这个场景的目的而改变。

关于我们应该如何重新思考设计方面的评论可能是正确的，但无济于事:)

我有一个非常大的表，大约 150 个字段宽，大约 600m 行，它驱动大量进程。这是在数据仓库情况下，因此我们在计划加载过程之外没有任何更新/插入，因此它被大量索引。

已决定尝试对该表进行分区，我对索引分区表有一些担忧。我没有任何分区经验，因此感谢任何输入或链接。我无法在 BOL 或 msdn 上具体找到我所追求的内容。

目前，我们聚集在一个我们称之为IncidentKeyavarchar(50)而非唯一的字段上——我们可以有 1-100 条相同的记录IK（请不要发表评论）。我们确实经常在旧IncidentKey记录上获取新数据，因此它也不是连续的。

我知道我需要IncidentDate在我的聚集索引键中包含我的分区字段 ,才能使分区正常工作。我想它会是IncidentKey, IncidentDate。

问题是，如果“新”分区中的记录应该在聚集索引中“旧”分区中的记录之前，聚集索引的机制将如何在分区表中的 2 部分键上工作？

例如，我有 5 条记录：

IncidentKey    Date

ABC123        1/1/2010
ABC123        7/1/2010
ABC123        1/1/2011
XYZ999        1/1/2010
XYZ999        7/1/2010

如果我得到一个新记录，ABC123, 2/1/2011它将需要在聚集索引BEFORE 中 XYZ999, 1/1/2010。这是如何运作的？

我假设有碎片和指针，但我找不到关于具有双部分键的分区表上非分区聚集索引的物理存储和配置的任何信息。

背景

我有一个由大约 2000 个传感器组成的网络，每个传感器都有大约 100 个数据点，我们每隔 10 分钟收集一次。这些数据点通常是 int 值，但有些是字符串和浮点数。这些数据应该存储 90 天，如果可能的话，更多并且仍然有效。

数据库设计

当最初负责这个项目时，我编写了一个 C# 应用程序，为每个传感器编写逗号分隔的文件。当时没有那么多，当有人想查看趋势时，我们会在 Excel 中打开 csv 并根据需要绘制图表。

事情发展了，我们切换到了 MySQL 数据库。我为每个传感器创建了一个表格（是的，我知道，很多表格！）；它运行良好，但有一些限制。有这么多表，显然不可能编写一个查询，在查找特定值时会在所有传感器中查找数据。

对于下一个版本，我切换到 Microsoft SQL Server Express，并将所有传感器数据放入一个大表中。这也有效，并让我们进行查询以在所有感兴趣的传感器中查找值。但是，我遇到了 Express 版本的 10GB 限制，并决定切换回 MySQL 而不是投资 SQL Server Standard。

问题

我对 MySQL 的性能和可扩展性很满意，但我不确定坚持所有数据在一个表中的方法是否最好。单个表中的 10GB 似乎要求不同的设计。我应该提到的是，仍然需要查询数据以绘制图形，而且我担心绘制图形的查询会出现性能问题，例如，一个传感器在整个 90 天内的温度数据。（换句话说，图形应该是快速生成的，而无需等待 SQL 对成堆的数据进行排序以隔离感兴趣的传感器。）

我应该以某种方式拆分此表以提高性能吗？或者有这么大的桌子也不是什么稀奇事？

我在 Sensor ID 和 Timestamp 列上有索引，这几乎是任何查询的定义边界。（即从时间 A 到时间 B 获取传感器 X 的数据）。

我已经阅读了一些关于分片和分区的内容，但在这种情况下不觉得这些是合适的。

编辑：

根据到目前为止的评论和答案，一些额外的信息可能会有所帮助：

非无限期存储：目前我不存储超过 90 天的数据。每天，我都会运行一个查询来删除超过 90 天的数据。如果将来它变得重要，我会存储更多，但现在已经足够了。这有助于控制大小和高性能（呃）。

引擎类型：最初的 MySQL 实现使用了 MyISAM。这次为新实现（一个数据表而不是多个）创建表时，他们默认为 InnoDB。我不相信我对其中一个有要求。

归一化：当然还有除了数据采集表之外的其他表。这些支持表存储诸如传感器的网络信息、用户的登录信息等内容。没有太多需要规范化的内容（据我所知）。数据表有这么多列的原因是每个传感器有这么多变量。（多个温度、光照水平、气压等）对我来说标准化意味着没有冗余数据或重复组。（至少对于 1NF。）对于给定的传感器，在特定时间存储所有值需要一行数据，并且那里不涉及 1:N 关系（我看到）。 …

系统视图sys.partitions有一列“行”，它是给定分区中的总行数。对于未分区的表（或只有一个分区，取决于您如何看待它），此列给出了表中的行数。

我很好奇这个列有多准确，我是否可以用它代替SELECT COUNT(1) FROM TableName. 我做了一些实验，创建一个表并添加几千行，删除几百行，再添加几千行等等，而且计数一直都在。但是，我有一张包含大约 7 亿行和几个索引的表。sys.partitions聚集索引的行再次失效，但是其他索引显示出一些细微的变化 (+-20k)。

有谁知道这一行是如何计算的，以及它是否像看起来一样准确？