标签: performance

我很难理解表分区的优缺点。我即将开始一个项目，该项目将有 8 个表，其中一个将是主数据表，将包含 180-260 百万条记录。因为它将是正确索引的表，所以我正在考虑将表记录限制为 2000 万，这样我将不得不创建 9-13 个表。

但我不太确定它将如何提高性能，因为它们将位于同一台机器上（32GB RAM）？

我正在使用 MySQL 并且表将是 MyISAM 并且大表将在 id 字段上有索引，并且没有进一步的复杂性，例如全文搜索等。

还请阐明表分区与数据库分区。

我正在做一个项目，我需要每天在一张表中更改大约 36K 条记录。我想知道什么会表现得更好：

1. 删除行并插入新行，或
2. 更新已经存在的行

对我来说，删除所有行并插入新行会更容易，但如果这会使表和索引碎片化并影响性能，那么我更愿意在可能的情况下进行更新并仅在必要时删除/插入。

这将是一项夜间服务，我不希望提高流程本身的速度。我更关心对这个表的查询性能，我已经有 8900 万条记录，以及这个每晚的过程将如何影响它。

对于这个夜间流程，我应该删除/插入记录还是应该更新现有记录（在可能的情况下）？

我的一台 PostgreSQL 服务器托管了几个 (1-3) 数据库，这些数据库接收恒定的数据流。数据不是特别结构化，它相当于当前时间和特定时刻的各种观察数据。数据速率相当高；一个数据库每天大约可以计算出 1 GB 的数据，而另一个数据库则大约是每天 1 GB 的数据。我不希望这个比率会增加。读取性能的优先级要低得多，目前是可以接受的。

在日志中，我有这条消息：

LOG:  checkpoints are occurring too frequently (15 seconds apart)
HINT:  Consider increasing the configuration parameter "checkpoint_segments".

该值当前设置为 16，这是由 提供的pgtune。

我应该考虑哪些设置来提高写入性能？我宁愿保持尽可能多的安全。考虑到传入的数据量，只要大部分数据完好无损，我可以接受在故障中丢失一些最近的数据。

编辑：我现在使用 PostgreSQL 9.0，但我计划升级到 9.1。我不会发布硬件细节，因为虽然我承认它们的重要性，但我最终将需要在具有非常不同硬件的几台机器上进行这种优化。如果硬件对答案至关重要，请给我一般信息，以便我可以将答案应用于具有不同硬件配置的机器。

有很多文章夸大了（当然恕我直言）对innodb_file_per_table. 我知道使用innodb_file_per_table，应该可以更好地控制各个表；比如分别备份每张表。然而，对更好性能的要求是有问题的。

在我的测试中，在性能没有差异innodb_file_per_table，并ibdata1为60GB的数据库。当然，这是一个普通查询的简单测试，现实生活中复杂查询的情况可能会有所不同（这就是我问这个问题的原因）。64 位 linux 搭配ext4可以有效处理大文件。

使用innodb_file_per_table，需要更多的磁盘 I/O 操作；这在复杂的JOINs 和FOREIGN KEY约束中很重要。

表空间在 single 上共享ibdata；单独表的专用表空间如何节省磁盘空间？当然，使用 为每个表释放表空间更容易ALTER，但它仍然是一个昂贵的过程（带有表锁）。

问：是否innodb_file_per_table有关于MySQL的性能更好的效果呢？如果是，为什么？

我今天才听说罗伯特·马丁，他似乎是软件界的一个显赫人物，所以我的头衔并不是说看起来像是一个点击诱饵或我在他嘴里说的话，但这只是我是如何以我有限的经验和理解来解释我从他那里听到的。

我在看一个视频今天（关于软件架构），Robert C. Martin 的演讲，在视频的后半部分，数据库的主题是主要焦点。

根据我对他所说的话的理解，他似乎是在说 SSD 会降低数据库的实用性（相当大）。

解释我是如何得出这种解释的：

他讨论了如何使用 HDD/旋转磁盘，检索数据很慢。然而，他指出，现在我们使用固态硬盘。他从“RAM 即将到来”开始，然后继续提到 RAM 磁盘，但随后说他不能称之为 RAM 磁盘，因此只说 RAM。所以对于 RAM，我们不需要索引，因为每个字节都需要相同的时间来获取。（这一段是我转述的）

因此，他建议 RAM（如在计算机内存中）作为 DB 的替代品（正如我将他的声明解释为那样）是没有意义的，因为这就像说所有记录在应用程序的生命周期内都在内存中处理（除非您根据需要从磁盘文件中提取）

所以，我用 RAM 来思考，他的意思是 SSD。因此，在这种情况下，他是说 SSD 会降低数据库的实用性。他甚至说：“如果我是甲骨文，我会害怕。我存在的根本原因正在消失。”

根据我对 SSD 的一点了解，与 HDD 不同，HDD 是O(n)寻道时间（我认为），SSD 接近O(1)或几乎是随机的。所以，他的建议对我来说很有趣，因为我从来没有这样想过。几年前我第一次接触数据库时，当一位教授描述与常规文件系统相比的好处时，我得出的结论是数据库的主要作用本质上是一个非常索引的文件系统（以及优化、缓存、并发访问、等），因此，如果 SSD 中不需要索引，这种类型确实会使数据库变得不那么有用。

尽管如此，以我是新手的开头，我发现很难相信它们变得不那么有用了，因为每个人仍然使用 DB 作为其应用程序的主要点，而不是纯粹的文件系统，并且感觉好像他过于简单化了数据库的作用。

注意：我确实一直看到最后，以确保他没有说不同的话。

供参考：42 : 22是整个数据库主题出现的时候， 43:52是他开始说“为什么我们甚至有数据库”的时候

这个答案确实说 SSD 大大加快了数据库的速度。 这个问题询问优化是如何改变的。

对于TL;DR我的问题，SSD 在服务器市场（无论是即将到来还是已经发生）的广泛使用是否会降低数据库的实用性？

似乎演示者试图传达的是，使用 SSD，人们可以将数据存储在磁盘上，而不必担心检索数据会像使用较旧的 HDD 一样慢，与使用 SSD 一样，寻道时间接近O(1)（我认为）。因此，如果这是真的，那么假设它会失去它所拥有的优势之一：索引，因为拥有索引以加快查找时间的优势已经不复存在。

我能够重现一个我认为出乎意料的查询性能问题。我正在寻找一个专注于内部的答案。

在我的机器上，以下查询执行聚集索引扫描并花费大约 6.8 秒的 CPU 时间：

SELECT ID1, ID2
FROM two_col_key_test WITH (FORCESCAN)
WHERE ID1 NOT IN
(
N'1', N'2',N'3', N'4', N'5',
N'6', N'7', N'8', N'9', N'10',
N'11', N'12',N'13', N'14', N'15',
N'16', N'17', N'18', N'19', N'20'
)
AND (ID1 = N'FILLER TEXT' AND ID2 >= N'' OR (ID1 > N'FILLER TEXT'))
ORDER BY ID1, ID2 OFFSET 12000000 ROWS FETCH FIRST 1 ROW ONLY
OPTION (MAXDOP 1);

以下查询执行聚集索引查找（唯一的区别是删除FORCESCAN提示），但需要大约 18.2 秒的 CPU 时间：

SELECT ID1, ID2
FROM two_col_key_test
WHERE ID1 …

我想从 6 列中获取最小值。

到目前为止，我已经找到了三种方法来实现这一点，但我担心这些方法的性能，并想知道哪种方法对性能更好。

第一种方法是使用大 case 语句。这是一个包含 3 列的示例，基于上面链接中的示例。我的案例陈述会更长，因为我将查看 6 列。

Select Id,
       Case When Col1 <= Col2 And Col1 <= Col3 Then Col1
            When Col2 <= Col3 Then Col2 
            Else Col3
            End As TheMin
From   MyTable

第二种选择是将UNION运算符与多个选择语句一起使用。我会把它放在一个接受 Id 参数的 UDF 中。

select Id, dbo.GetMinimumFromMyTable(Id)
from MyTable

和

select min(col)
from
(
    select col1 [col] from MyTable where Id = @id
    union all
    select col2 from MyTable where Id = @id
    union all
    select col3 …

我知道存储过程通过执行路径更有效（比应用程序中的内联 sql）。然而，当被按下时，我对原因不是很了解。

我想知道对此的技术推理（以稍后我可以向某人解释的方式）。

谁能帮我制定一个好的答案？

我有一个数据库，我将文件加载到临时表中，从这个临时表我有 1-2 个连接来解析一些外键，然后将这些行插入到最终表中（每个月有一个分区）。我有大约 34 亿行数据，用于三个月的数据。

将这些行暂存到最终表中的最快方法是什么？SSIS 数据流任务（使用视图作为源并具有快速加载活动）或插入 INTO SELECT .... 命令？我尝试了数据流任务，可以在大约 5 小时内获得大约 10 亿行（服务器上有 8 个内核/192 GB RAM），这对我来说感觉很慢。

考虑一个值和哈希表，如下所示：

+------------+----------+------+-----+---------+----------------+
| Field      | Type     | Null | Key | Default | Extra          |
+------------+----------+------+-----+---------+----------------+
| id         | int(11)  | NO   | PRI | NULL    | auto_increment |
| val        | char(9)  | NO   |     | NULL    |                |
| val_hashed | char(50) | YES  |     | NULL    |                |
+------------+----------+------+-----+---------+----------------+

以下查询在 0.00 秒内完成：

SELECT * FROM hashes ORDER BY 1 DESC LIMIT 1;

但是，此查询需要 3 分 17 秒：

SELECT val FROM hashes ORDER BY 1 DESC LIMIT 1; …