如何存储大批量小文件_SecureFiles压缩与去重Deduplication-Oracle-PHP中文网

SecureFiles 不提供压缩或去重能力，其存储的是原始字节流；压缩需应用层预处理，去重须依赖哈希（推荐 SHA256）与唯一索引配合实现，小文件盲目压缩反而增体积。

SecureFiles 本身不提供压缩或去重能力

mysql 的 securefiles 是一种存储大对象（blob/text）的底层引擎，它比旧的 myisam 风格的 legacyfiles 更安全、更高效，但它不负责压缩，也不做内容去重。你看到的“压缩”效果，往往来自上层配置或外部工具；而“去重”必须由应用层或专用存储系统实现。

常见错误现象：SHOW VARIABLES LIKE 'innodb_file_per_table' 或 innodb_file_format 被误认为控制压缩——其实它们只影响表空间组织方式；启用 ROW_FORMAT=COMPRESSED 也仅对 InnoDB 表数据页有效，对 SecureFiles 存储的 BLOB 内容无直接作用。

SecureFiles 存储的是原始字节流，MySQL 不解析其内容，因此无法基于内容哈希判断重复
若用 COMPRESSED 行格式建表，BLOB 字段仍以明文存入 SecureFiles，压缩发生在页级，不可控且不适用于小文件场景
真正想压缩小文件，得在写入前用 zlib.compress()、lz4.frame.compress() 等处理字节，再存为 BLOB

大批量小文件该用什么存：别硬塞进 MySQL

每秒写入数百个 1–10 KiB 的文件到 SecureFiles，会迅速暴露瓶颈：事务开销高、ibdata1 膨胀快、备份恢复慢、主从延迟飙升。这不是设计目标，而是反模式。

典型使用场景：用户上传头像、日志切片、IoT 设备采集的小传感器包、CI 构建产物缓存——这些更适合对象存储或专用文件系统。

用 S3 / MinIO + 前端加 ETag（即 MD5/SHA256）做客户端去重，服务端可配合 PUT 时检查 If-None-Match
本地部署选 WORM（Write Once Read Many）支持好的方案，如 borgbackup 或 restic，它们天然带内容定义块（content-defined chunking）和全局去重
若必须用 MySQL，把小文件聚合成大块再存，比如按小时/用户 ID 打包成 TAR 或 ZIP，并单独维护索引表记录内部路径与偏移

手动实现去重的关键点：哈希不能只靠 MD5

想在数据库里自己做去重，核心是“内容相同 → ID 相同”。但只算 MD5(file_bytes) 很危险：碰撞概率低不等于零，且 MySQL 的 MD5() 函数不支持二进制输入，容易因字符集转换出错。

性能与兼容性影响明显：在 INSERT ... SELECT 中实时计算 SHA256，会使写入吞吐下降 3–5 倍；而把哈希存在单独列并建唯一索引，又要求应用层严格保证一致性。

务必用 SHA2(file_bytes, 256) 替代 MD5()，且在应用层用 hashlib.sha256() 计算后以 hex 形式传入，避免 MySQL 自动编码转换
哈希列类型推荐 CHAR(64)（SHA256 hex）+ COLLATE ascii_bin，防止大小写或空格隐式转换
不要依赖 INSERT IGNORE 或 ON DUPLICATE KEY UPDATE 做“存在则跳过”，需先 SELECT 查哈希，再决定 INSERT 或复用 ID——否则并发写入可能漏判