报错#1136或字段数不匹配,本质是phpMyAdmin将CSV首行列名误作数据插入,导致类型冲突或列数不符;必须勾选“第一行包含列名”,确认CSV为UTF-8无BOM、字段顺序与表结构完全一致,并确保字符集全程为utf8mb4。
报错#1136或字段数不匹配,先看CSV第一行是不是被当数据用了
这类报错本质是phpmyadmin把csv首行列名当成了真实数据插入,而目标表字段类型(比如int)根本接不住字符串"id"。不是分隔符错了,也不是文件损坏,就是没跳过标题行。
- 务必在导入页面勾选
First line contains column names(第一行包含列名) - 用VS Code或Notepad++打开CSV,肉眼确认第一行确实是纯字段名,且没有隐藏BOM(开头没出现)
- 字段顺序必须和表结构完全一致——
id,name,email对应表中id INT, name VARCHAR, email VARCHAR;若CSV是email,name,id,即使勾了选项也会错位 - 别信Excel保存时显示的“CSV UTF-8”,它实际输出的是UTF-8 with BOM,会干扰首字段识别
中文变问号或方块,别只调phpMyAdmin字符集下拉框
界面上选utf8mb4只是告诉phpMyAdmin“按这个编码读文件”,但MySQL连接层可能还是latin1,数据进表前就被二次解码搞乱了。
- 导入前在phpMyAdmin的SQL标签页手动执行:
SET NAMES utf8mb4; - 运行
SELECT @@character_set_client;确认返回值是utf8mb4,不是latin1 - 检查目标表字段定义:
SHOW CREATE TABLE your_table;,确保每列末尾有CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci - CSV文件本身必须是UTF-8 without BOM:Notepad++里选“编码 → 转为UTF-8”,不是“以UTF-8编码保存”
上传卡住、报413或“0行已插入”,不是CSV有问题而是PHP或Web服务器限制
大文件导入失败,90%和CSV内容无关,纯粹是PHP进程或Nginx/Apache拦住了请求体。
使用 qbo-mileage CLI 及用户凭证,从 Airtable、Outlook 或 Google Calendar 记录生成 QuickBooks Online 里程 CSV 文件。
- 检查
php.ini:调大upload_max_filesize、post_max_size、max_execution_time,改完必须重启PHP - Nginx用户加配置:
client_max_body_size 100M;(放在http/server/location块里) - Apache用户检查
LimitRequestBody是否设得太小 - 更稳的替代方案:把CSV压缩成
.zip再上传——phpMyAdmin支持自动解压,能绕过部分上传限制
字段截断或静默丢数据,查VARCHAR长度和隐藏换行符
MySQL不会报错,只会默默砍掉超长部分。一个汉字在utf8mb4下占4字节,但VARCHAR(10)限制的是字符数,不是字节数——所以存10个汉字没问题,但存11个就会丢最后一个。
- 用
DESCRIBE table_name;查各字段的CHARACTER_MAXIMUM_LENGTH - 用
SELECT HEX(column_name) FROM table_name LIMIT 1;看是否有隐藏\n或未闭合双引号导致解析错位 - 字段含逗号、引号、换行时,必须用双引号包裹,且内部引号要转义为
"",否则phpMyAdmin会误判行结束 - 别关
STRICT_TRANS_TABLES来掩盖问题——关了之后照样截断,只是不提醒你
php免费学习视频:立即使用
踏上前端学习之旅,开启通往精通之路!从前端基础到项目实战,循序渐进,一步一个脚印,迈向巅峰!










