<p>报错#1366 - Incorrect integer value: 'id' for column 'id' at row 1，本质是CSV首行列名被误当数据插入：需勾选“第一行包含列名”，并严格核对CSV列顺序与表结构是否一致，同时检查NOT NULL字段是否为空或类型不匹配。</p>
字段溢出报错（如 #1366 - incorrect integer value 或静默截断）不是数据“太大”，而是类型不匹配或首行被当数据用了——必须跳过标题行、确认字段顺序、检查目标列是否允许 null。
导入时提示 #1366 - Incorrect integer value: 'id' for column 'id' at row 1
这是最典型的“字段溢出”误判：报错内容里的 'id' 是 CSV 第一行的列名，不是真实数据。phpMyAdmin 把它当第一行记录插进去了，而目标表 id 是整型、不允许字符串，立刻炸。
- 务必勾选导入页的“第一行包含列名”，否则所有列名都会被当成非法值塞进对应字段
- 检查 CSV 列顺序是否和表结构完全一致——
id,name,email对应表id INT, name VARCHAR, email VARCHAR；如果 CSV 是email,name,id，即使勾了“第一行含列名”，也会把邮箱值插进id字段，触发 #1366 - 若表中某列为
NOT NULL且无默认值，但 CSV 对应列为空（比如空字符串""），phpMyAdmin 可能转成NULL导致报错；此时需补全数据，或临时改列为NULL
字段内容被无声截断（如 VARCHAR(10) 存了 12 个汉字只留前 10 个）
MySQL 不会报错，只会默默丢掉超长部分。这和 max_allowed_packet 或严格模式无关，纯属字段定义长度不足。
- 用
DESCRIBE table_name;查目标字段的CHARACTER_MAXIMUM_LENGTH，注意 VARCHAR 长度单位是字符数，不是字节数；utf8mb4 下一个汉字占 4 字节，但长度计为 1 - 确认 CSV 字段里有没有隐藏换行符（
\n）或未闭合双引号——这类字符会让 phpMyAdmin 解析错位，导致后续字段整体偏移，看起来像“某字段变短了” - 别关
STRICT_TRANS_TABLES来掩盖问题：关了之后超长字段照样截断，只是不报错，数据损坏更难发现
大数据量下报内存溢出或卡在“0 行已插入”
这不是字段溢出，但常被误认为是。本质是 PHP 进程扛不住，连解析都没完成，自然没数据插入。
QuickBooks Mileage CSV
下载
使用 qbo-mileage CLI 及用户凭证，从 Airtable、Outlook 或 Google Calendar 记录生成 QuickBooks Online 里程 CSV 文件。
- 单文件超过 2MB 或 5 万行，基本不要指望 phpMyAdmin 能稳住；错误可能是
Fatal error: Allowed memory size exhausted或直接白屏 - 拆分优先于调参：用
split -l 10000 data.csv chunk_（Linux/macOS）或 PowerShell 的Get-Content data.csv | Select-Object -First 10000 | Set-Content chunk_1.csv（Windows）切块，每块控制在 500KB 内 - 如果服务器可访问命令行，改用
LOAD DATA INFILE：它绕过 PHP，由 MySQL 直接读文件，速度和稳定性都碾压 phpMyAdmin；但要求文件在数据库服务器本地，且用户有FILE权限
最容易被忽略的是：字段溢出类报错，90% 源于 CSV 结构和表结构没对齐，而不是数据本身有问题。先开文本编辑器看前三行真实内容，再比对表 SHOW CREATE TABLE 输出，比反复调 sql_mode 有用得多。
立即学习“PHP免费学习笔记（深入）”；
