简介：这份资源面向具备一定C#基础的开发者，聚焦于将照片等二进制文件写入MySQL数据库这一常见需求，帮助解决媒体文件持久化存储与读取的工程问题。压缩包共48个文件，约333KB，包含7个cs源码文件、1个sln解决方案、1个sql脚本以及config、resx、resources等配置与资源文件，另有exe、dll、pdb等编译产物，整体结构完整，可直接运行调试。内容围绕File.ReadAllBytes读取图片字节、MySqlConnection建立连接、BLOB字段建表以及参数化查询插入数据等关键环节展开，并配有Dump20170419.sql数据库脚本，便于快速还原表结构与测试数据。目前已有2013人学习下载，适合正在开发用户上传照片、社交或博客类应用的C#开发者参考，可借此掌握二进制数据处理、数据库连接与SQL防注入的完整实现思路。
1. 把照片塞进 MySQL：什么时候该做，什么时候纯属自找麻烦
先说结论：把照片存进 MySQL 这件事，技术上完全可行，但它是那种「做之前想清楚，做之后不后悔」的典型场景。我见过太多 C# 上位机项目，一开始图省事把图片直接塞进数据库，跑半年数据量上来之后，备份慢、查询卡、迁移难，最后又花大力气把图片挪回文件系统。所以这篇不是劝你一定这么干，而是把「什么情况下该存、怎么存、参数怎么调、坑在哪」讲透，让你自己判断。
核心做法就一句话：在 C# 里把图片读成字节数组，通过参数化 SQL 写进 MySQL 的BLOB字段，读的时候再取出来还原成图片。听起来简单，但真正落地时，字段类型选BLOB还是LONGBLOB、连接串要不要开AllowLoadLocalInfile、max_allowed_packet设多大、大图会不会把内存打爆，每一步都有讲究。适合谁看：做 C# 上位机、工控采集、考勤系统、设备巡检这类需要「图片和业务记录强绑定」的开发者。如果你的图片是海量相册、视频封面这种，老老实实存文件系统加路径，别折腾数据库。
2. 先搞懂 BLOB 和连接层：为什么你的图片写进去变成乱码
2.1 MySQL 四种 BLOB 类型到底怎么选
MySQL 的二进制大对象类型有四种，容量和用途差别很大，选错了要么存不下，要么白白浪费空间。很多人第一次建表随手写个BLOB，结果一张 2MB 的照片直接报Data too long，这就是没搞清楚容量上限。
| 类型 | 最大容量 | 典型用途 |
|---|---|---|
| TINYBLOB | 255 字节 | 图标、缩略图极小图 |
| BLOB | 64 KB | 小图标、指纹模板 |
| MEDIUMBLOB | 16 MB | 普通照片、证件照 |
| LONGBLOB | 4 GB | 高清图、扫描件、大附件 |
我一般会直接上MEDIUMBLOB，因为现在手机随手一拍就是 2～5MB，BLOB的 64KB 根本不够看。只有确定是扫描件、工程图纸这种动辄几十 MB 的，才用LONGBLOB。注意容量上限是「单条记录该字段」的上限，不是整表，别混淆。
建表语句我通常这么写，把图片和业务字段放一起，方便强绑定：
CREATE TABLE device_photo ( id BIGINT AUTO_INCREMENT PRIMARY KEY, device_no VARCHAR(64) NOT NULL COMMENT '设备编号', shoot_time DATETIME NOT NULL COMMENT '拍摄时间', photo_name VARCHAR(128) COMMENT '原始文件名', photo_data MEDIUMBLOB COMMENT '图片二进制', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_device (device_no) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;这里photo_data用MEDIUMBLOB，device_no建索引是为了按设备查图。别在photo_data上建索引，二进制大字段建索引既没意义又拖慢写入。
2.2 连接串和 max_allowed_packet：图片写不进去的头号元凶
图片写不进去，十有八九是max_allowed_packet太小。这个参数控制 MySQL 服务端和客户端单次通信包的最大值，默认在 MySQL 8.0 里是 64MB，但很多老版本或者被人改过的实例只有 4MB 甚至 1MB。你一张 5MB 的图，包一超就直接断连报错。
先查当前值：
SHOW VARIABLES LIKE 'max_allowed_packet';如果偏小，临时改（重启失效）：
SET GLOBAL max_allowed_packet = 67108864; -- 64MB永久改要动配置文件my.ini（Windows）或my.cnf（Linux），在[mysqld]段加：
[mysqld] max_allowed_packet = 64M改完重启 MySQL 服务。血泪经验：这个值要设成比你最大图片还大一圈，比如最大图 10MB，就设 32MB 留余量，因为协议还有额外开销。
C# 连接串这边，用 MySqlConnector 或官方 Connector/NET 都行，关键是别踩字符集的坑。存二进制一定要确保连接用的是二进制安全的方式，参数化传byte[]本身是安全的，但如果你手贱把字节数组转成字符串再拼 SQL，那必然乱码。连接串示例：
Server=127.0.0.1;Port=3306;Database=testdb;Uid=root;Pwd=yourpwd;CharSet=utf8mb4;SslMode=None;AllowUserVariables=True;CharSet=utf8mb4是给文本字段用的，二进制字段不受它影响，但统一设好省心。SslMode=None仅限内网自测，生产环境按需开。
3. C# 读写图片的完整代码：从 FileStream 到参数化 SQL
3.1 把图片读成 byte[] 并写入数据库
先装包，用 NuGet 装MySqlConnector（比官方 Connector/NET 更活跃、异步支持更好）：
dotnet add package MySqlConnector写入的核心代码：
using MySqlConnector; using System.IO; public async Task SavePhotoAsync(string deviceNo, string filePath) { // 1. 把图片文件读成字节数组 byte[] photoBytes = await File.ReadAllBytesAsync(filePath); // 2. 参数化 SQL，绝不拼字符串 const string sql = @" INSERT INTO device_photo (device_no, shoot_time, photo_name, photo_data) VALUES (@deviceNo, @shootTime, @photoName, @photoData);"; await using var conn = new MySqlConnection("Server=127.0.0.1;Database=testdb;Uid=root;Pwd=yourpwd;"); await conn.OpenAsync(); await using var cmd = new MySqlCommand(sql, conn); cmd.Parameters.AddWithValue("@deviceNo", deviceNo); cmd.Parameters.AddWithValue("@shootTime", DateTime.Now); cmd.Parameters.AddWithValue("@photoName", Path.GetFileName(filePath)); // 关键：二进制参数用 MySqlDbType.Blob 明确类型 cmd.Parameters.Add("@photoData", MySqlDbType.Blob).Value = photoBytes; await cmd.ExecuteNonQueryAsync(); }逻辑说明：File.ReadAllBytesAsync一次性把文件读进内存，适合中小图。参数@photoData必须显式指定MySqlDbType.Blob，如果只用AddWithValue让驱动猜类型，某些版本会把它当字符串处理，导致写入损坏。MySqlDbType.Blob对应的是BLOB家族，驱动会根据实际长度适配，不用你手动区分 MEDIUMBLOB。
参数说明：deviceNo是业务主键，shootTime记录拍摄时间，photoName存原始文件名方便追溯，photoData就是二进制本体。如果你的图超过几十 MB，别用ReadAllBytes，改用流式分块，否则内存直接飙上去。
3.2 从数据库读回图片并落盘
读回来同样简单，但要注意GetBytes和GetValue的区别：
public async Task LoadPhotoAsync(long id, string savePath) { const string sql = "SELECT photo_name, photo_data FROM device_photo WHERE id = @id;"; await using var conn = new MySqlConnection("Server=127.0.0.1;Database=testdb;Uid=root;Pwd=yourpwd;"); await conn.OpenAsync(); await using var cmd = new MySqlCommand(sql, conn); cmd.Parameters.AddWithValue("@id", id); await using var reader = await cmd.ExecuteReaderAsync(); if (await reader.ReadAsync()) { // 直接取 byte[]，驱动已还原二进制 byte[] data = (byte[])reader["photo_data"]; await File.WriteAllBytesAsync(savePath, data); } }逻辑说明：reader["photo_data"]返回的是byte[]，直接强转即可。如果字段可能为 NULL，先reader.IsDBNull(1)判断。参数@id是主键，走主键索引查询很快。
参数说明：savePath是落盘路径，建议用Path.Combine拼，别手写反斜杠。大图落盘用WriteAllBytesAsync同样吃内存，超大文件建议用FileStream分块写。
3.3 用存储过程封装批量写入
如果一次要写多张图，逐条 INSERT 效率低，可以用存储过程配合事务。先建过程：
DELIMITER $$ CREATE PROCEDURE sp_insert_photo( IN p_device_no VARCHAR(64), IN p_shoot_time DATETIME, IN p_photo_name VARCHAR(128), IN p_photo_data MEDIUMBLOB ) BEGIN INSERT INTO device_photo (device_no, shoot_time, photo_name, photo_data) VALUES (p_device_no, p_shoot_time, p_photo_name, p_photo_data); END$$ DELIMITER ;C# 调用：
cmd.CommandType = System.Data.CommandType.StoredProcedure; cmd.CommandText = "sp_insert_photo"; cmd.Parameters.AddWithValue("@p_device_no", deviceNo); cmd.Parameters.AddWithValue("@p_shoot_time", DateTime.Now); cmd.Parameters.AddWithValue("@p_photo_name", fileName); cmd.Parameters.Add("@p_photo_data", MySqlDbType.Blob).Value = photoBytes; await cmd.ExecuteNonQueryAsync();逻辑说明：存储过程把 SQL 逻辑收进数据库，C# 端只传参，适合多端复用同一套写入规则。参数名要和过程定义一致，MySqlDbType.Blob同样不能省。
参数说明：p_photo_data用MEDIUMBLOB入参，和表字段对齐。批量场景建议把多条 INSERT 包在一个事务里，减少提交次数。
4. 避坑与排查：图片存 MySQL 最常见的 5 个翻车现场
4.1 报错 Data too long for column
现象：插入时报Data too long for column 'photo_data'。原因：字段类型容量不够，比如用了BLOB（64KB）却存 2MB 的图。解决：把字段改成MEDIUMBLOB或LONGBLOB，用ALTER TABLE device_photo MODIFY photo_data MEDIUMBLOB;。改之前确认现有数据不会丢。
4.2 写入成功但读出来图片打不开
现象：数据库里明明有数据，读出来文件大小也对，但图片查看器打不开。原因：写入时把byte[]当字符串处理了，比如用了AddWithValue没指定类型，或者中途做了Encoding.UTF8.GetString转换。解决：写入参数必须显式MySqlDbType.Blob，全程不碰字符串编码转换，二进制就是二进制。
4.3 大图导致连接中断或超时
现象：小图正常，超过几 MB 就报连接被重置或超时。原因：max_allowed_packet太小，或者net_write_timeout太短。解决：调大max_allowed_packet到 64M 以上，同时把net_write_timeout和net_read_timeout适当调大，比如 600 秒。连接串里也可以加ConnectionTimeout和DefaultCommandTimeout。
4.4 备份和迁移变得极慢
现象：mysqldump导出带图片的库，几 GB 起步，恢复要几个小时。原因：二进制大字段让单表体积暴涨，备份文件巨大。解决：这是架构层面的问题，如果图片量确实大，考虑图片存文件系统、数据库只存路径；或者用mysqldump时排除大字段表，图片单独用工具同步。别指望数据库备份能像纯文本表那么轻快。
4.5 内存暴涨甚至 OOM
现象：批量处理几百张图时程序内存飙升，最后OutOfMemoryException。原因：ReadAllBytes和WriteAllBytes都是一次性全读进内存，加上DataTable缓存，内存翻倍。解决：改用流式读写，FileStream分块读，配合MySqlCommand的流式参数；查询时用CommandBehavior.SequentialAccess逐段读 BLOB，别一次性GetValue。
5. 进阶技巧：让图片存储既稳又快的三个习惯
第一个习惯是给图片做「瘦身」再入库。我一般会在 C# 端用System.Drawing（.NET Framework）或ImageSharp（跨平台）把图压到合理尺寸再存，比如长边不超过 1920 像素、JPEG 质量 80。这样一张图从 5MB 降到 300KB，数据库压力小一个数量级。压缩代码不复杂，关键是别把原图无脑塞进去。
第二个习惯是读写分离加缓存。图片一旦写入基本不变，读的时候可以在 C# 端加一层内存缓存（比如MemoryCache），按id缓存最近访问的图片字节，避免频繁查库。对于高频访问的图，这一层能省掉大量 IO。
第三个习惯是定期做「冷热分离」。超过一定时间的图片，可以归档到单独的归档表甚至文件系统，主表只留近期数据。这样主表体积可控，查询和备份都快。归档用定时任务跑，别手动。
验证方法很简单：写一个循环，连续插入 1000 张 1MB 的图，观察耗时和内存曲线；再连续读 1000 次，看缓存命中前后的 QPS 差异。我自己的经验是，不加压缩和缓存，1000 张图写入要几十秒、内存峰值几百 MB；加上压缩和流式处理后，时间砍半、内存平稳。这套方案值不值得做，取决于你的图片量和业务耦合度——强绑定、量不大，存数据库很省心；量大又独立，还是文件系统加路径更靠谱。希望帮到你。
本文还有配套的精品资源，点击获取
