直接用字符串拼接sql插入blob必然乱码或截断；安全插入核心是绕过字符集转换，mysql必须用参数化查询或_binary前缀，应用层须用setblob()等原生二进制接口，纯sql手动插入必须加_binary前缀，文本类可用cast/convert但需编码严格一致。
直接用字符串拼接 SQL 插入 BLOB，99% 会乱码或截断；安全插入的核心是绕过字符集转换、避免隐式类型转换、按数据库机制走原生二进制路径。
MySQL：必须用参数化查询或 _binary 前缀
MySQL 不允许把二进制数据当普通字符串处理。连接字符集（如 utf8mb4）一参与，'' 就变成乱码字节流。
- 应用层写法（Java/Python/C++）必须用
PreparedStatement.setBlob()或cursor.execute("INSERT ...", (binary_data,))，不能用execute("INSERT ... '" + hex_data + "'") - 纯 SQL 手动插入时，必须加
_binary前缀：INSERT INTO t(blob_col) VALUES (_binary'\xff\xd8\xff'); - 若插的是 JSON/XML 等文本的二进制编码，可用
CAST(... AS BLOB)或CONVERT(... USING utf8mb4)，但前提是原始编码与 CONVERT 中指定的一致 -
LOAD_FILE()只能在服务端本地文件使用，且 MySQL 用户需有FILE权限，不适用于客户端上传场景
SQL Server：用 VARBINARY(MAX) + 参数化，别碰 IMAGE
IMAGE 类型已废弃多年，不能用 LEN()、不支持函数运算、无法参数化传入，强行用会报错或静默失败。
- 建表必须用
VARBINARY(MAX)，不是IMAGE - 存储过程或应用代码中，参数声明为
@data VARBINARY(MAX)，然后UPDATE t SET col = @data即可，无需分段 - 单次插入超 2MB 时，检查
max server memory配置，否则可能触发内存溢出 - 真正大文件（如 >10MB）应启用
FILESTREAM，让数据存 NTFS，数据库只存指针，否则日志和备份体积爆炸
PostgreSQL：BYTEA 必须 encode/decode，驱动默认转十六进制
psycopg2、pgx 等主流驱动不会直传二进制流，而是把 BYTEA 转成 8b... 字符串再发——这本身是安全的，但你不能手动拼这个字符串，也不能依赖 encode() 结果直接 INSERT。
- 插入时用参数化：驱动自动处理
bytea类型绑定，例如 Python 中cursor.execute("INSERT ...", (binary_data,)) - 手动 SQL 插入必须用
decode('7f8b...', 'hex')，不能写'8b...'（部分客户端不识别） - 读取后若要还原为二进制，需用
encode(col, 'hex')或直接取 bytes 类型值（取决于驱动配置） - 不要在存储过程中对
BYTEA做字符串操作（如substring()），它不是文本
Oracle 和 SQLite：一个太重，一个太轻
Oracle 要求先占位再写，SQLite 则几乎只要参数化就稳——两者都不适合“手写 INSERT VALUES (xxx)”这种模式。
- Oracle 存储过程里插入 BLOB，必须：
INSERT ... VALUES (EMPTY_BLOB()) ... FOR UPDATE→SELECT blob_col INTO :lob_var ... FOR UPDATE→DBMS_LOB.WRITEAPPEND()分段写（每次 ≤32767 字节） - SQLite 完全支持参数化插入 BLOB，
sqlite3_bind_blob()或 Python 的cursor.execute("INSERT...", (data,))即可；但注意max_page_count和 WAL 模式，大 BLOB 会显著拖慢事务 - 所有数据库中，BLOB 超过几 MB 后，都该考虑「存路径、不存内容」——数据库不是文件系统，膨胀和锁竞争比你想象得更早到来
