简介：这份PHP程序面向需要将Excel表格数据批量迁移至MySQL数据库的开发者，尤其适合后台数据导入、系统初始化或日常数据同步等场景。程序通过读取xls文件内容，按指定数据库名、数据表及字段写入，支持中文处理，保存编码为UTF-8，使用前需保证文件为xls格式且表头与数据库字段一一对应。压缩包共4个文件，以3个php脚本和1个inc包含文件为主，分别承担上传、Excel解析与数据插入等职责，整体仅13KB，结构轻量、便于二次修改与集成。目前已有277人学习下载，说明其在同类数据导入需求中具备一定参考价值。读者可借此掌握PHP读取xls并写入MySQL的完整实现思路，理解表头字段映射、中文编码处理与导入格式限制等关键细节，也可直接基于现有脚本调整数据库配置，快速搭建符合自身业务的数据导入流程。
1. 把 Excel 表格塞进 MySQL：为什么“能跑”和“敢用”是两码事
后台运营丢过来一个 Excel，说“这是本周要上架的商品，你导一下”。你打开一看，列名是中文，日期格式五花八门，价格列里混着“￥”和空格，还有几行是合并单元格。这时候你写个fgetcsv或者file_get_contents直接怼进数据库，大概率能跑通——然后第二天运营说“有几条数据怎么没了”，你才发现某一行因为编码问题被静默截断。
xls 导入 MySQL 的 PHP 程序，核心要解决的不是“怎么读文件”，而是“怎么在脏数据、大文件、重复导入这三件事同时存在时，还能保证结果可预期”。它适合两类人：一类是刚接手后台导入功能、想找个能直接抄的骨架的开发者；另一类是被线上导入任务坑过、想回头补上校验和幂等逻辑的熟手。下面按“先能跑、再跑稳、最后跑快”的顺序拆开讲，每一步都落到能复制的代码和能改的参数上。
2. 选对读取方式：PHP 读 xls 的三种路线与取舍
2.1 先分清 xls 和 xlsx，别用错扩展名
很多人把.xls和.xlsx混着叫，但它们在 PHP 里是两套完全不同的解析路径。.xls是老的二进制 BIFF 格式，.xlsx本质是一个 zip 包，里面是 XML。如果你用PHPExcel时代的代码去读.xlsx，或者用PhpSpreadsheet去读一个被改过后缀的.xls，最常见的结果是抛一个Could not open file或者读到空数组。
判断真实格式不要看后缀，看文件头。.xls的前几个字节是D0 CF 11 E0，.xlsx是50 4B 03 04（也就是 zip 的PK）。我一般会在入口处加一段探测：
<?php // 探测真实文件类型，避免后缀欺骗 function detectExcelType(string $path): string { $fh = fopen($path, 'rb'); $head = fread($fh, 8); fclose($fh); $hex = bin2hex($head); if (str_starts_with($hex, 'd0cf11e0')) { return 'xls'; // 老 BIFF 二进制 } if (str_starts_with($hex, '504b0304')) { return 'xlsx'; // zip + xml } return 'unknown'; }这段逻辑说明：只读前 8 字节，开销可以忽略，但能挡掉“运营把 xlsx 另存为 xls”这类高频事故。参数上不需要调，返回unknown时直接拒绝并提示用户重新导出，比后面解析到一半报错要好排查得多。
2.2 PhpSpreadsheet 与原生 XML 的选型对比
选型上，常见做法是PhpSpreadsheet，它封装了 xls 和 xlsx 的差异，API 统一。但它的内存占用在“只读”场景下并不理想，默认会把整个工作表加载成对象树。如果你只是要把数据搬进 MySQL，不需要样式、公式、图表，那用PhpSpreadsheet的setReadDataOnly(true)能省掉一部分，但大文件仍然吃紧。
另一条路是只针对.xlsx用XMLReader流式读sheet1.xml，内存几乎恒定。代价是你要自己处理共享字符串表（sharedStrings.xml）和单元格坐标换算。对于.xls二进制，流式解析要自己拆 BIFF 记录，成本太高，不建议手写。
我的取舍是：文件小于 5MB、列数少于 50，直接用PhpSpreadsheet，开发快；超过这个量级，或者导入是定时任务，就要求运营导出.xlsx，走XMLReader流式路线。下面给一个PhpSpreadsheet的最小读取骨架，先保证能跑通。
<?php require 'vendor/autoload.php'; use PhpOffice\PhpSpreadsheet\IOFactory; function readRows(string $path): array { $reader = IOFactory::createReaderForFile($path); $reader->setReadDataOnly(true); // 不读样式，省内存 $reader->setReadEmptyCells(false); // 跳过空单元格 $sheet = $reader->load($path)->getActiveSheet(); $rows = []; foreach ($sheet->getRowIterator() as $row) { $line = []; $cellIterator = $row->getCellIterator(); $cellIterator->setIterateOnlyExistingCells(false); foreach ($cellIterator as $cell) { $line[] = $cell->getValue(); } $rows[] = $line; } return $rows; }逻辑说明：createReaderForFile会根据文件头自动选 xls 或 xlsx 的 reader，比手动new Xls()稳。setReadDataOnly(true)是关键参数，它让解析器跳过样式和公式计算，实测能把内存峰值压掉一半左右。setIterateOnlyExistingCells(false)保证空列也占位，否则后面按列索引取值会错位。注意getValue()拿到的是原始值，日期会变成 Excel 序列号（比如 45000 这种），需要单独转换，这个坑在下一章展开。
2.3 用命令行先验证读取结果，再写入库
不要一上来就写“读 + 入库”一体的脚本。我习惯先写一个只读的 CLI 脚本，把前 10 行打印出来，确认列顺序、编码、日期格式都对得上，再去接数据库。这样出问题时能立刻判断是读取阶段还是写入阶段。
php read_preview.php /path/to/goods.xls输出里重点看三样：第一行是不是表头、中文有没有乱码、日期列显示的是数字还是字符串。如果中文乱码，多半是文件本身编码不是 UTF-8，需要在读取后做一次转码；如果日期是数字，说明要按 Excel 的日期序列号规则还原。这一步花两分钟，能省掉后面半小时的排查。
3. 从行数据到 SQL：字段映射、类型转换与批量插入
3.1 建立列名到数据库字段的映射表
Excel 的列顺序经常变，运营加一列“备注”就可能让后面的字段全部错位。所以不要用固定下标取值，而是先读表头，建立“中文列名 → 数据库字段”的映射。常见做法是维护一个配置数组：
<?php // 列名映射：Excel 表头 => 数据库字段 $columnMap = [ '商品名称' => 'title', '售价' => 'price', '库存' => 'stock', '上架日期' => 'online_at', '分类' => 'category_id', ];读取时先拿第一行做表头，用array_flip或循环匹配，把每一列的值归到对应字段。遇到映射表里没有的列，直接忽略并在日志里记一笔，而不是报错中断——运营加列是常态，不能因为多一列就整批失败。参数上，映射表建议放在配置文件或数据库里，不要硬编码在脚本中，方便不同业务线复用。
3.2 日期、价格、布尔值的转换规则
Excel 里的日期存的是从 1900-01-01 开始的天数（有个 1900 闰年 bug，Excel 自己处理了）。PHP 里还原要用\PhpOffice\PhpSpreadsheet\Shared\Date::excelToDateTimeObject()，不要自己拿strtotime去猜。价格列要先去除非数字字符，再转成decimal能接受的字符串。布尔值常见的是“是/否”“Y/N”，统一映射成 1/0。
<?php use PhpOffice\PhpSpreadsheet\Shared\Date; function normalizeRow(array $raw, array $map): array { $out = []; foreach ($map as $excelCol => $dbField) { $val = $raw[$excelCol] ?? null; switch ($dbField) { case 'online_at': // Excel 序列号转日期字符串 $val = is_numeric($val) ? Date::excelToDateTimeObject($val)->format('Y-m-d') : date('Y-m-d', strtotime((string)$val)); break; case 'price': // 去掉 ￥、空格、千分位逗号 $val = preg_replace('/[^\d.]/', '', (string)$val); $val = $val === '' ? '0.00' : number_format((float)$val, 2, '.', ''); break; case 'stock': $val = (int)$val; break; default: $val = trim((string)$val); } $out[$dbField] = $val; } return $out; }逻辑说明：excelToDateTimeObject处理了序列号和闰年问题，比自己算可靠。价格用正则只保留数字和小数点，能挡掉“￥1,299.00”这种写法。number_format保证入库时是两位小数的字符串，避免浮点误差。注意stock直接转 int，如果 Excel 里写的是“暂无”，会变成 0，这个要在校验阶段拦，不能等到入库。
3.3 批量插入：一次 500 行，用预处理语句
逐行INSERT在几千行时还能忍，上万行就会把连接拖垮。常见做法是拼批量INSERT INTO ... VALUES (...), (...), ...，但要注意单条 SQL 的长度限制（max_allowed_packet）。我一般每 500 行提交一批，用 PDO 的预处理占位符，既防注入又比字符串拼接快。
<?php function batchInsert(PDO $pdo, array $rows): void { if (empty($rows)) { return; } $fields = array_keys($rows[0]); $cols = implode('`, `', $fields); $place = '(' . implode(',', array_fill(0, count($fields), '?')) . ')'; $chunks = array_chunk($rows, 500); // 每批 500 行 $sql = "INSERT INTO `goods` (`$cols`) VALUES " . implode(',', array_fill(0, count($chunks[0]), $place)); $stmt = $pdo->prepare($sql); foreach ($chunks as $chunk) { $params = []; foreach ($chunk as $row) { foreach ($fields as $f) { $params[] = $row[$f]; } } $stmt->execute($params); } }逻辑说明：array_chunk的 500 是经验值，字段多的时候要往下调，保证拼出来的 SQL 不超过max_allowed_packet（默认 4MB 或 16MB，看版本）。$place按字段数生成占位符，$params按行展开，顺序必须和$fields一致，否则会串列。执行前建议开事务，整批失败能回滚，避免导入一半留下脏数据。
3.4 用事务包住整批导入，失败可回滚
导入最怕的是“前 3000 行进去了，第 3001 行报错，剩下全没导”。用beginTransaction包住整个批次，任何一批抛异常就rollBack，让数据库回到导入前的状态。代价是事务日志会变大，所以批次不要太大，500 行一批配合事务比较平衡。
<?php $pdo->beginTransaction(); try { foreach ($chunks as $chunk) { // 上面的批量插入逻辑 } $pdo->commit(); } catch (Throwable $e) { $pdo->rollBack(); error_log('导入失败：' . $e->getMessage()); throw $e; }注意：如果表引擎是 MyISAM，事务不生效，必须确认是 InnoDB。这个在导入前用SHOW TABLE STATUS看一眼，能避免“以为回滚了其实没有”的翻车。
4. 避坑与排查：导入程序最容易翻车的五个点
4.1 中文乱码：现象是入库后全是问号
现象：Excel 里中文正常，导入后数据库里显示???或者乱码方块。原因通常是文件本身是 GBK 编码，而 PHP 按 UTF-8 读，或者数据库连接字符集不是utf8mb4。解决分两步：先确认文件编码，用mb_detect_encoding探测，必要时mb_convert_encoding($val, 'UTF-8', 'GBK')；再确认 PDO 连接串里带了charset=utf8mb4。两个都做对，乱码基本消失。
4.2 日期变成 45000 这种数字
现象：online_at字段入库后是45000而不是2023-03-15。原因是 Excel 把日期存成序列号，getValue()拿到的就是数字。解决是用Date::excelToDateTimeObject()转换，不要用date('Y-m-d', $val)直接怼，那样会得到 1970 年附近的时间。如果转换后日期差一天，检查时区设置，Excel 的序列号基准和 PHP 时区可能不一致。
4.3 重复导入导致数据翻倍
现象：同一个文件导了两次，商品表里出现两份相同数据。原因是没做幂等。解决有两个方向：一是给业务字段加唯一索引，用INSERT ... ON DUPLICATE KEY UPDATE；二是在导入前先按批次号删除旧数据。我一般用前者，配合一个batch_no字段，重复导入时更新而不是新增。注意唯一索引要建在真正唯一的字段组合上，建错了会导致正常数据也插不进去。
4.4 大文件导致内存溢出
现象：导入 10MB 的 xls 时 PHP 报Allowed memory size exhausted。原因是PhpSpreadsheet默认把整个文件加载进内存。解决：优先让运营导出.xlsx并走XMLReader流式读取；如果只能用 xls，调大memory_limit只是缓兵之计，根本办法是分批读——但 xls 二进制不支持随机行读取，所以实际中还是推动格式统一更靠谱。
4.5 空行和合并单元格导致列错位
现象：导入后某些行的字段整体偏移一列。原因是 Excel 里有空行或合并单元格，getRowIterator遇到空行时行为不一致。解决：在读每一行时先判断是否全空，全空则跳过；合并单元格只有左上角有值，其余为 null，需要在映射时做兜底，用上一行的值填充或直接报错让运营拆开。这个坑没有银弹，只能靠预览脚本提前发现。
5. 进阶技巧：把导入做成可重跑、可观测的任务
5.1 加一个导入日志表，记录每批的结果
导入不是一次性的，运营会反复导。建一张import_log表，字段包括批次号、文件名、总行数、成功行数、失败行数、失败原因、开始和结束时间。每次导入写一条，出问题时能直接查“这批为什么少了 3 行”。这个表不需要复杂结构，但能省掉大量“到底导没导进去”的扯皮。
CREATE TABLE `import_log` ( `id` BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, `batch_no` VARCHAR(32) NOT NULL, `file_name` VARCHAR(255) NOT NULL, `total_rows` INT UNSIGNED NOT NULL DEFAULT 0, `ok_rows` INT UNSIGNED NOT NULL DEFAULT 0, `fail_rows` INT UNSIGNED NOT NULL DEFAULT 0, `fail_reason` TEXT, `started_at` DATETIME NOT NULL, `finished_at` DATETIME NULL, KEY `idx_batch` (`batch_no`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;逻辑说明：batch_no用时间戳加随机串生成，导入时先插一条“进行中”，结束后更新成功/失败行数和结束时间。fail_reason存前几条失败原因即可，不用全存，避免日志表膨胀。有了这张表，排查时先看fail_rows是不是 0，再看fail_reason，定位速度比翻 PHP 日志快得多。
5.2 用校验行数做导入前后的对账
导入前先数一遍 Excel 的有效行数（去掉表头和空行），导入后查SELECT COUNT(*)对比。如果对不上，说明有行被静默丢弃。这个对账逻辑放在导入脚本的最后，不通过就告警。参数上，允许的误差是 0，因为导入是确定性操作，少一行都说明有问题。
<?php $excelRows = count(array_filter($rows, fn($r) => array_filter($r))); $dbRows = $pdo->query("SELECT COUNT(*) FROM goods WHERE batch_no = " . $pdo->quote($batchNo))->fetchColumn(); if ($excelRows !== (int)$dbRows) { error_log("对账失败：Excel {$excelRows} 行，入库 {$dbRows} 行"); }注意array_filter($r)用来判断行是否全空，空行不计入。这个对账逻辑简单，但能抓住大部分“看起来成功其实丢数据”的情况。
5.3 把导入拆成“解析”和“入库”两个阶段
最后一个习惯：不要把解析和入库写在一个循环里。先完整解析成数组（或临时文件），确认行数和字段都对，再统一入库。这样解析阶段的错误不会污染数据库，入库阶段的错误也能用事务回滚。代价是内存占用翻倍，所以大文件走流式时，解析阶段直接写临时表，入库阶段再从临时表搬。这个拆分让排查边界清晰：解析错了看读取代码，入库错了看 SQL 和约束。
我踩过最深的一次坑，是没做对账就上线，运营说“导了 500 行”，实际入库 497 行，差了 3 行合并单元格。后来加了行数对账和导入日志，这类问题再没漏过。希望帮到你。
本文还有配套的精品资源，点击获取
