不推荐在生产环境用 BLOB 存文件，因其导致表膨胀、备份慢、主从延迟、max_allowed_packet 错误；仅适用于小元数据、临时中转或短生命周期强一致场景；主流做法是存路径于 VARCHAR 并将文件置于对象存储。
MySQL 中 BLOB 字段存文件到底靠不靠谱？
不推荐直接用 blob 存文件，尤其是生产环境。它会让表体积暴涨、备份变慢、主从同步延迟升高，还容易触发 max_allowed_packet 错误导致插入失败。
真正适合的场景只有：小尺寸元数据（如用户头像缩略图 ≤100KB）、临时中转、或强一致性要求且生命周期极短的二进制内容。
-
TINYBLOB（≤255 字节）适合存加密盐值、小图标 -
BLOB（≤64KB）勉强能存 base64 编码的 SVG 或极简 PNG -
MEDIUMBLOB（≤16MB）是多数“试水项目”的实际上限，但已明显拖累查询性能 -
LONGBLOB（≤4GB）几乎等于自建文件系统，运维成本远超收益
替代方案：为什么该把文件路径存 VARCHAR 而不是 BLOB？
把文件存在磁盘或对象存储（如 S3、MinIO），数据库只存路径或唯一 ID，才是主流做法。这样分离关注点，也避免数据库成为 I/O 瓶颈。
关键不是“能不能”，而是“值不值得”——BLOB 字段会让 SELECT * 变成灾难，哪怕只查 1 行，也可能拉取几 MB 二进制数据。
- 路径字段建议用
VARCHAR(512)，足够覆盖带哈希前缀的 S3 URL 或本地相对路径 - 如果需要校验完整性，额外加一列
file_hash CHAR(64)（存 SHA-256） - 删除记录时，记得异步清理对应文件，别只删 DB —— 这是最常漏掉的一步
INSERT 含 BLOB 数据时总报错 Packet too large 怎么办？
这是 MySQL 客户端/服务端对单次传输包大小的限制，和 BLOB 类型本身无关，但会最先暴露出来。
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
改配置只是权宜之计，治标不治本；真要传大文件，应该走流式上传 + 分片处理，而不是塞进一条 SQL。
- 服务端调大
max_allowed_packet（需重启或动态 SET，但有内存压力） - 客户端连接时显式设置：如 Python 的
pymysql.connect(..., max_allowed_packet=128*1024*1024) - 更稳妥的做法：用
LOAD_FILE()函数（需开启secure_file_priv且文件在服务端） - 绝对不要用字符串拼接方式构造含
BLOB的 SQL —— 二进制数据会破坏语义，极易出错
ORM 框架里读写 BLOB 字段的常见翻车点
很多 ORM 默认把 BLOB 映射成 bytes 或 bytearray，看着简单，实际容易吃光内存或卡死连接。
尤其在分页查询或批量导出时，一个 BLOB 字段就能让整批结果集膨胀数倍。
- Django 的
BinaryField默认加载全部内容，要用.values_list('id', 'filename')避开BLOB列 - SQLAlchemy 的
LargeBinary支持延迟加载（defer()），但得手动加，否则照单全收 - Java 的 MyBatis 若用
resultType="map"，BLOB可能被转成byte[]却没做长度判断，OOM 风险高 - 所有框架都默认不压缩
BLOB内容，别指望它自动帮你 gzip —— 压缩必须由业务层决定何时压、压多少
最麻烦的不是存不下，是查的时候才发现它一直在那儿，安静又沉重。
