相关疑难解决方法(0)

存储与数据库中数据相关的二进制文件的最佳位置是什么？你应该：

1. 使用 blob 存储在数据库中
2. 使用数据库中的链接存储在文件系统上
3. 存储在文件系统中但重命名为内容的散列并将散列存储在数据库中
4. 我没有想到的东西

(1) 的优点是（除其他外）事务的原子性得以保留。代价是您可能会显着增加存储（和相关的流/备份）要求

(3) 的目标是在某种程度上保留原子性 - 如果您可以强制您正在写入的文件系统不允许更改或删除文件，并且始终具有正确的哈希作为文件名。这个想法是在允许引用哈希的插入/更新之前将文件写入文件系统 - 如果此事务在文件系统写入之后但在数据库 DML 之前失败，那很好，因为文件系统“假装”是所有的存储库可能的文件和哈希值 - 是否有一些文件没有被指向并不重要（如果你小心的话，你可以定期清理它们）

编辑：

看起来一些 RDBMS 以各自的方式涵盖了这一点 - 我很想知道其他人是如何做到的 - 特别是在 postgres 的解决方案中

可能的重复：
文件 - 在数据库中与否？

我想知道是否有任何充分的理由仍然在数据库中使用 blob 字段。几年前，我使用了一个包含一堆图像的数据库，该数据库非常慢，我看不出有什么好的理由将图像保存在数据库中，所以我将图像取出并存储了文件名反而。

这是明智之举吗？你代替我做什么？

我使用 mysqldump 创建一个用于备份的平面文件。我已使用此文件在备用服务器上重新创建数据库。我在命令行上通过 ssh 运行导入过程，但收到多个Packet too Large错误。

我用更大的 max_allowed_pa​​cket（即 1000M）重新启动了 mysql，但仍然收到错误消息。我什至尝试在导入文件中设置 max_allowed_pa​​cket，仍然收到错误。

有没有办法确保设置 max_allowed_pa​​cket 和/或使用 mysqldump 来创建不会导致此问题的文件？

以供参考：

未压缩的 mysqldump 文件约为 2GB

数据库类型是 INNODB

我有一个表，用于存储每个大小在 16-100 KB 之间的图像。由于图像太小，我采纳了Microsoft 的建议，没有使用 FILESTREAM 数据类型。该表的构造很简单：

CREATE TABLE Screenshot(
         Id bigint NOT NULL,
         Data varbinary(max) NOT NULL,
CONSTRAINT PK_Screenshot PRIMARY KEY CLUSTERED 
(
Id ASC
)WITH (PAD_INDEX  = OFF, 
   STATISTICS_NORECOMPUTE  = OFF, 
   IGNORE_DUP_KEY = OFF, 
   ALLOW_ROW_LOCKS  = ON, 
   ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]

该表被大量插入（过去一周有 200 万条记录）并且很少被选中。关键是使用hilo 算法，因此大多数情况下会在末尾添加新行。

由于锁定和争用，当许多进程尝试插入到该表中时，我一直遇到问题。查询因等待锁定而超时。

我应该将此表迁移到它自己的文件组和驱动器吗？在这种情况下，如何提高插入性能并减少争用？