简介一份面向C#开发者的完整示例工程演示如何将照片以二进制形式存入MySQL数据库适合需要处理图片上传、文件存储与数据库交互的初学者参考。压缩包共48个文件以C#源码.cs为核心附带SQL脚本、可执行文件、配置及资源文件等整体仅333KB轻量且结构清晰便于直接对照学习。已有2013人学习下载。通过源码和说明可掌握File.ReadAllBytes读取图片、MySqlConnection连接数据库、BLOB字段设计以及参数化插入等关键操作配套的Dump20170419.sql备份文件更支持快速导入库表进行验证。对于开发社交网络、个人博客等涉及用户照片存储功能的场景这份资料能提供直观的入门路径和可复用的代码范式。1. C# 照片存储到 MySQL先想清楚这张照片值不值得进库做某一个积分商城后台时我遇到过最尴尬的一次线上事故商品图片传上去后页面偶尔能显示、偶尔裂开运维排查半天发现是服务器磁盘写满了上传的图片文件丢失了一半而数据库里还留着这些文件的路径。从那天起我把照片入库方案从“存路径”彻底改成了“存二进制”用 C# 把照片转成 byte[] 直接塞进 MySQL 的 BLOB 字段。这篇文章就是把那套折腾过、验证过的做法完整拆给你什么时候值得存库、表怎么建、代码怎么写、哪些参数最容易翻车以及照片入库后怎么读出来、怎么优化性能。2. 存路径还是存二进制为什么我最终选了 BLOB 方案2.1 路径方案的三类翻车现场先聊最常见的做法客户端上传照片服务器把文件写到磁盘目录数据库里只存一个相对的 URL 路径比如/uploads/2024/03/abc.jpg。这套方案看起来没毛病但上线三个月后各种问题就冒出来了。第一类是文件与数据库记录不一致。用户上传了一照片Web 层先存文件、再写数据库结果数据库事务回滚了文件却留在了磁盘上反过来管理员删掉一条商品记录时只删了数据库行忘了删文件垃圾文件越积越多。你说写个定时任务去清扫那还得比对数据库和磁盘逻辑不复杂但很恶心。第二类是多实例部署时的共享问题。应用做了负载均衡两台服务器都在跑用户上传的图片落在 A 机器下一次请求被转发到 B 机器B 机器上根本没有这个文件。常见的补救是搭一个 NFS 共享目录或者对象存储那这架构复杂度就上来了而且文件服务和数据库是两个系统出问题更难排查。第三类是备份与恢复的割裂。数据库可以用 mysqldump 或者 xtrabackup 做备份但磁盘上的图片文件得单独备份一份。你恢复数据库的时候很容易忘了恢复文件目录或者文件备份滞后导致数据库里有记录、文件却是旧的页面上展示的图片张冠李戴。2.2 BLOB 方案的三笔账体积、备份、性能BLOBBinary Large Object方案是把照片的字节数组直接存进 MySQL 的大字段里。它的核心优势是强一致照片和业务记录在同一个事务里写入要么都成功、要么都失败不存在文件残留问题备份也简单整个数据库一把梭恢复时不会出现“库有文件无”的尴尬。但代价也得看清。第一笔账是数据库体积膨胀。一张 500KB 的照片一万张就是 5GB十万人上传就是 500GB数据库文件体积上去了mysqldump备份时间、恢复时间都会明显变长。第二笔账是主从复制的压力照片进 binlog 之后从库同步的网络开销和磁盘 IO 都会增加。第三笔账是大字段读写比普通字段更耗内存SELECT *的时候哪怕你只想要一条记录的 id也会把整张照片的字节拉进内存。所以我的判断标准是照片单张小于 1MB、总量可控比如不超过几十 GB、业务对一致性和事务要求高的场景无脑选 BLOB照片量大、单张几个 MB、主要是展示场景那就老老实实走对象存储别折腾数据库。2.3 我的选型底线什么场景可以直接存库给一个可以直接照抄的判断清单单张照片经过压缩后小于 500KB照片总量预估小于 20GB业务要求照片必须和主记录强一致比如用户头像、合同附件、工单截图团队不想维护一套独立的文件存储服务。以上四条全部满足BLOB 方案是成本最低的选择。我那个积分商城项目商品图片压到 300KB 左右、总共几千张存库一点问题没有。如果哪一天图片量涨到几十万张我可能会迁移到对象存储但那是后话先把当前的稳定性和一致性搞定。3. 建表与连接准备BLOB 四档选型与连接串参数边界3.1 TINYBLOB 到 LONGBLOB 怎么选MySQL 提供了四种 BLOB 类型区别主要在最大容量和存储字节数前缀的开销类型最大容量字节数前缀适合场景TINYBLOB255 字节1 字节头像缩略图、极小的图标BLOB64 KB2 字节小尺寸截图、压缩后的文档预览图MEDIUMBLOB16 MB3 字节压缩后的照片、PDF 文件LONGBLOB4 GB4 字节原图、视频文件我在实际项目里用最多的是 MEDIUMBLOB。原因很直接照片经过压缩处理之后一般不会超过 16MBMEDIUMBLOB 刚好覆盖这个区间而且它的索引开销和数据文件占用都比 LONGBLOB 小。用 LONGBLOB 存小照片属于“杀鸡用牛刀”BLOB 字段的元数据开销不说某些 ORM 对 LONGBLOB 的类型映射还会多绕一圈。3.2 连接串三个易错参数的边界连接字符串是一个门槛不高但坑不少的东西。我常用的模板长这样Server127.0.0.1;Port3306;Databasephoto_db;Uidroot;Pwdyour_password;Charsetutf8mb4;Connection Timeout30;AllowLoadLocalInfilefalse;Max Pool Size100第一个易错参数是Charset。默认情况下 Connector 可能用latin1连接这会导致文件名、业务备注这些字符串字段写入时变乱码。注意BLOB 字段本身不受字符集影响——它存的是字节但同一张表的file_name字段是字符串如果不统一走utf8mb4你存进去的中文文件名读出来就是“???”照片能显示但文件名叫人看不懂。第二个易错参数是Connection Timeout。默认 15 秒看起来够用但如果数据库和业务服务器之间有网络波动或者数据库负载高建立连接超时是常客。我一般会设到 30 秒同时配合连接池的重试逻辑。第三个易错参数是AllowLoadLocalInfile。MySQL 服务器如果开着local-infile而连接串也允许加载本地文件存在被恶意利用读文件的风险。我这边的默认做法是显式关掉线上环境尤其要注意。3.3 建表 SQL字段、字符集、索引一次定好下面是我实测可用的建表语句结构上考虑了“照片 业务信息 检索”三层需要CREATE TABLE photo_archive ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, file_name VARCHAR(255) NOT NULL COMMENT 原始文件名仅用于展示, file_ext VARCHAR(10) NOT NULL COMMENT 扩展名jpg/png/webp, content_type VARCHAR(80) NOT NULL COMMENT MIME类型, image_data MEDIUMBLOB NOT NULL COMMENT 压缩后的照片字节, thumb_data MEDIUMBLOB NULL COMMENT 缩略图字节列表页读取, file_size INT UNSIGNED NOT NULL COMMENT 字节数, width SMALLINT UNSIGNED NULL COMMENT 像素宽度, height SMALLINT UNSIGNED NULL COMMENT 像素高度, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_created_at (created_at), KEY idx_file_name_prefix (file_name(64)) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这段 SQL 里有几个设计点要说清楚。thumb_data字段是我强烈建议提前预留的列表页读取缩略图而不是原图能省掉 90% 的流量后面进阶章节会专门讲。file_size存的是压缩后的字节数查统计报表时直接 SUM 就行不用每次去读 LENGTH(image_data)。索引方面BLOB 字段不能建普通索引所以索引放在created_at和时间范围查询上file_name(64)前缀索引是给用户按文件名搜索用的没必要给整列建索引。提示如果你的 MySQL 版本比较老最后一行CREATE TABLE后记得确认innodb_file_format支持 Barracuda否则大字段可能走溢出页导致性能下降。4. C# 把照片写进 MySQL读取、压缩、参数化插入的一条龙代码4.1 从文件到 byte[]File.ReadAllBytes 与流式读取的取舍入门的写法是File.ReadAllBytes(path)一行代码把整个文件读进内存byte[] imageBytes File.ReadAllBytes(C:\photos\IMG_001.jpg);逻辑很简单但这里有一个“视觉盲区”如果照片是 5MB、10MBReadAllBytes会一次性分配同等大小的字节数组。看似无所谓可如果做批量导库一次读 100 张内存直接吃掉 500MB。我的习惯是分场景单张上传用ReadAllBytes完全够用批量导入必须走流式。using var fs new FileStream(filePath, FileMode.Open, FileAccess.Read); using var ms new MemoryStream(); await fs.CopyToAsync(ms); byte[] imageBytes ms.ToArray();fs.CopyToAsync(ms)使用的是流式拷贝底层会分块读取不会一次性把整个文件映射到托管堆。ms.ToArray()最后还是会复制一份出来但至少避免了“文件读取 字节处理”同时吃两份大内存。注意MemoryStream.ToArray()是拷贝而不是取内部缓冲区这个细节在内存紧张时要心里有数。4.2 插入前的压缩一张 5MB 照片怎么压到 300KB这是整个方案里最值得花时间的步骤。即使你决定存库也尽量不要把 5MB 的原图直接塞进去。我的压缩参数是目标宽 1280px、JPEG 质量 75实测一张手机拍的 5MB 照片压到 300KB 左右肉眼在 Web 端基本看不出差别。using System.Drawing; using System.Drawing.Drawing2D; using System.Drawing.Imaging; public static byte[] CompressImage(byte[] sourceBytes, int targetWidth 1280, long quality 75L) { using var inMs new MemoryStream(sourceBytes); using var sourceImg Image.FromStream(inMs); int newWidth Math.Min(targetWidth, sourceImg.Width); int newHeight (int)(sourceImg.Height * (newWidth / (double)sourceImg.Width)); using var resized new Bitmap(newWidth, newHeight); using var g Graphics.FromImage(resized); g.InterpolationMode InterpolationMode.HighQualityBicubic; g.SmoothingMode SmoothingMode.HighQuality; g.DrawImage(sourceImg, 0, 0, newWidth, newHeight); using var outMs new MemoryStream(); var jpegCodec ImageCodecInfo.GetImageEncoders() .FirstOrDefault(c c.FormatID ImageFormat.Jpeg.Guid); var parameters new EncoderParameters(1); parameters.Param[0] new EncoderParameter(Encoder.Quality, quality); resized.Save(outMs, jpegCodec, parameters); return outMs.ToArray(); }InterpolationMode.HighQualityBicubic是缩略图缩放里失真最小的插值算法quality用 75 是一个兼顾体积和画质的经验值低于 60 会出现明显的马赛克条纹。Image.FromStream读取时要求流的位置在开头如果你传入的是MemoryStream注意检查Position是否为 0。另外这段代码基于System.Drawing.Common在 Linux 上跑需要安装libgdiplus如果部署环境是纯 Linux 容器且不想装系统库我一般会换成跨平台的 ImageSharp 库核心逻辑不用变只是Save那一层不一样。注意文件夹路径和文件路径里如果包含中文记得确认 Linux 服务器的区域设置是 UTF-8否则FileStream打开文件时可能抛“找不到文件”的异常。4.3 参数化插入MySqlParameter 设置 BLOB 的写法写入最怕两件事SQL 注入和类型推断错误。参数化是唯一正解但AddWithValue在这里是个暗坑using MySql.Data.MySqlClient; private static string _connectionString Server127.0.0.1;Port3306;Databasephoto_db;Uidroot;Pwdyour_password;Charsetutf8mb4;Connection Timeout30;AllowLoadLocalInfilefalse;; public static async Task InsertPhotoAsync(string filePath, string fileName) { byte[] imageBytes; using (var fs new FileStream(filePath, FileMode.Open, FileAccess.Read)) using (var ms new MemoryStream()) { await fs.CopyToAsync(ms); imageBytes ms.ToArray(); } byte[] compressed CompressImage(imageBytes, 1280, 75L); const string sql INSERT INTO photo_archive (file_name, file_ext, content_type, image_data, file_size, width, height) VALUES (fileName, fileExt, contentType, imageData, fileSize, width, height); using var conn new MySqlConnection(_connectionString); await conn.OpenAsync(); using var cmd new MySqlCommand(sql, conn); cmd.Parameters.Add(fileName, MySqlDbType.VarChar, 255).Value fileName; cmd.Parameters.Add(fileExt, MySqlDbType.VarChar, 10).Value Path.GetExtension(fileName); cmd.Parameters.Add(contentType, MySqlDbType.VarChar, 80).Value GetContentType(fileName); cmd.Parameters.Add(imageData, MySqlDbType.MediumBlob).Value compressed; cmd.Parameters.Add(fileSize, MySqlDbType.Int32).Value compressed.Length; using var img Image.FromStream(new MemoryStream(compressed)); cmd.Parameters.Add(width, MySqlDbType.Int32).Value img.Width; cmd.Parameters.Add(height, MySqlDbType.Int32).Value img.Height; await cmd.ExecuteNonQueryAsync(); }这里最关键的一行是cmd.Parameters.Add(imageData, MySqlDbType.MediumBlob).Value compressed。如果你用AddWithValue(imageData, compressed)驱动会按默认规则推断类型结果很可能推断成LONGBLOB或者某种不确定的类型一旦和表结构的MEDIUMBLOB不匹配插入阶段不报错但读取阶段可能因为字节长度前缀不一致而读不出完整数据。这是最典型的“玄学”问题我在下一章的避坑记录里还会展开。参数fileSize存的是压缩后的长度所以它在compressed生成之后才赋值width和height需要先解码图片这里用MemoryStream临时包一层再释放避免Image对象锁住流导致后续程序无法操作文件。5. 照片入库避坑记录五个必踩的坑与排查路径5.1 坑一插入后读出来是 byte[]但图片打不开现象数据库里能看到image_data字段有值用 C# 读出来是System.Byte[]但转成Image时抛“参数无效”或者写出来的文件不是合法图片。原因最常见的是写入时用的是AddWithValue(imageData, byteArray)MySQL 驱动把字节数组推断成了某种文本类型或者长度不匹配的 BLOB导致字节在存储时被悄悄做了转换。其次是存储过程或者 ORM 映射时把byte[]属性映射成了string类型。解决写入时强制显式声明MySqlDbType.MediumBlob并且用一个干净的MemoryStream从文件流拷贝不要对字节数组做任何编码转换。读取时直接用GetBytes或者ExecuteScalar拿原始字节不要经过ToString()。byte[] bytes (byte[])command.ExecuteScalar(); using var ms new MemoryStream(bytes); using var img Image.FromStream(ms);5.2 坑二照片超过 1MB写入直接报 PacketTooLarge现象小图插入成功超过 1MB 的图插入时报MySqlException: Packets larger than max_allowed_packet are not allowed。原因MySQL 服务器的max_allowed_packet默认值是 4MB 或更小照片字节流超过这个限制时连接会被服务器强制断开报错信息还特别难懂。解决修改服务器参数在my.cnf的[mysqld]段下加一行[mysqld] max_allowed_packet 128M改完记得重启 MySQL 服务。这个参数是服务器端限制连接串里没有对应开关很多人在 C# 代码里找半天找不到解决办法。另外注意max_allowed_packet是指单个数据包的大小一次插入多个照片时按最大值累计批量插入要留足够余量。5.3 坑三Listbyte[] 里的照片顺序对但展示全乱现象批量读取照片后图片列表的缩略图全部错位第一行显示的是第二张照片第二张显示的是第三张看起来像“随机播放”。原因先读了DataReader里的普通字段文件名、大小再读image_data时没有按照列顺序读取或者直接用了GetOrdinal之后又使用GetBytes(0, ...)这种带索引的重载索引对不上。解决用列名读取不要用数字索引。顺序读取时先取普通字段再取 BLOB 字段并且保持SELECT语句里列的顺序与GetOrdinal结果一致。using var cmd new MySqlCommand(SELECT id, image_data FROM photo_archive WHERE id id, conn); using var reader cmd.ExecuteReader(); if (reader.Read()) { int id reader.GetInt32(id); long len reader.GetBytes(reader.GetOrdinal(image_data), 0, null, 0, 0); byte[] data new byte[len]; reader.GetBytes(reader.GetOrdinal(image_data), 0, data, 0, (int)len); }5.4 坑四中文文件名全部变成问号现象插入时传入的fileName商品主图.jpg读出来变成???或者数据库里直接是乱码。原因连接字符串没有指定Charsetutf8mb4默认用了latin1中文被转成?存进去。还有可能是建表时的DEFAULT CHARSET不是utf8mb4只是字段单独建错了字符集。解决三处统一。连接串加Charsetutf8mb4建表语句DEFAULT CHARSETutf8mb4如果需要修改已经存在的表用ALTER TABLE photo_archive CONVERT TO CHARACTER SET utf8mb4。修改完重新插入测试记录中文路径和中文文件名都要测。5.5 坑五批量插入 1000 张照片跑了半小时还没结束现象for 循环里一条一条插入1000 张照片耗时超过 30 分钟用户体验完全不可接受。原因每次ExecuteNonQueryAsync都是一次独立的数据库写操作包含连接池获取、事务提交、日志同步。照片字段又是几百 KB 的大字段网络传输和磁盘写入的时间被单条提交放大。解决用事务批量提交每 50 条Commit一次同时把插入语句改成多行 VALUES 的写法。实测从 30 分钟降到 2 分钟以内关键代码如下using var conn new MySqlConnection(_connectionString); await conn.OpenAsync(); using var tx await conn.BeginTransactionAsync(); for (int i 0; i photos.Count; i) { // 组装参数并 ExecuteNonQuery但先不提交 await cmd.ExecuteNonQueryAsync(); if (i % 50 0) { await tx.CommitAsync(); tx await conn.BeginTransactionAsync(); } } await tx.CommitAsync();注意事务里如果有一步失败要RollbackAsync并把已提交的部分记录日志避免半批数据入库后没有对账依据。我在项目里会把每次提交的 ID 范围写进一张photo_import_log表失败了可以直接从断点重导。6. 读取照片与进阶玩法从 byte[] 到 Image、缩略图缓存与分页加载先给一个最直接的读取方法用ExecuteScalar拿单条记录的image_data转成MemoryStream再交给Image.FromStream处理。这里有一个原则性的习惯拿到byte[]之后不要直接持有Image.FromStream创建的Image对象因为Image.FromStream会锁定流你必须先Clone出一份再释放流或者干脆把字节数组写到一个临时文件用pictureBox.Load()加载。实践中我更推荐第二种读法它看起来“笨”但稳定public static async Taskbyte[] GetPhotoBytesAsync(int id) { using var conn new MySqlConnection(_connectionString); await conn.OpenAsync(); using var cmd new MySqlCommand(SELECT image_data FROM photo_archive WHERE id id, conn); cmd.Parameters.Add(id, MySqlDbType.Int32).Value id; var result await cmd.ExecuteScalarAsync(); return result as byte[]; } public static Image BytesToImage(byte[] data) { using var ms new MemoryStream(data); return Image.FromStream(ms); }这段代码的逻辑说明ExecuteScalarAsync返回的是object强转byte[]前先用as做类型判断避免 null 引用。BytesToImage里using释放了MemoryStream但Image.FromStream要求流在对象存活期间保持打开所以这个方法只在“取出字节马上用完”的临时场景下用长生命周期场景必须Clone。进阶玩法是我强烈建议每一个存库项目都做的建表时预留的thumb_data字段在插入时同步生成 320px 宽的缩略图字节。列表页只SELECT id, file_name, thumb_data, file_size详情页才用GetPhotoBytesAsync读原图。这样列表接口的返回体从平均 300KB 降到 15KB流量消耗直接下降 95%数据库 IO 也少了一大截。分页加载方面不要在业务层用Skip/Take去查 BLOB 表我的做法是先分页查一张“照片索引”轻量表拿到当前页的 id 列表再WHERE id IN (...)去读缩略图字段。原因是 MySQL 的LIMIT offset偏移越大越慢而先用轻量索引缩小结果集大字段的读取次数也就稳定可控了。最后补一个上传权限的细节照片表里加一个owner_id字段读取接口的 SQL 强制带owner_id currentUserId条件不要因为是内部系统就省掉。那次积分商城的事故让我养成了两个习惯任何文件入库前必须先压缩并生成缩略图任何 BLOB 读取必须确认字段类型和读取方式后再写进正式代码。这条流程后来帮我在某图像处理 Demo 项目里省了整整两天的返工时间希望帮到你。本文还有配套的精品资源点击获取