必须用bigint unsigned或decimal(20,0)存19位数字，且csv不能经excel处理、字符集需统一为utf8mb4，否则mysql静默截断导致精度丢失。
因为 phpmyadmin 本身不处理数值精度，它把 csv 字段原样交给 mysql 解析；而 mysql 在遇到超长数字（如 18 位微信 openid、19 位 bigint）时，若目标字段是 int 或 decimal 但长度不足，就会截断或转成浮点近似值——这不是导入失败，是静默精度丢失。
MySQL 接收时就已丢精度，不是 phpMyAdmin 的锅
phpMyAdmin 只负责把 CSV 行按分隔符切开、拼成 INSERT 语句，真正执行的是 MySQL。当你看到 122121197410180016 变成 122121197410180000，说明 MySQL 把它当整数解析时超出了 BIGINT 精确范围（2^63−1 ≈ 9.2e18），或目标字段定义太小（比如 INT(11) 最大只到 2147483647）。
- 用
SHOW CREATE TABLE your_table检查字段类型：必须是BIGINT UNSIGNED或足够宽的DECIMAL(20,0)才能存 19 位数字 - 如果字段是
VARCHAR却仍丢精度，说明 CSV 里该字段被 Excel 处理过（见下一条） - phpMyAdmin 不会主动转换类型，也不会报错——它信任你给的字段定义
Excel 预处理过的 CSV 已经埋雷
如果你的 CSV 是从 Excel 另存为生成的，那大概率在保存时就被 Excel 强制转成了科学计数法或砍掉了末尾数字（比如身份证 110101199003072317 → 110101199003072000）。这种丢失发生在导出环节，phpMyAdmin 导入时只是忠实地把错误值插进去。
- 用 VS Code 或
head -n 1 data.csv直接看原始内容，确认数字是否还是完整字符串（如"122121197410180016"） - 若看到
1.2212119741018e+17或末尾是000，说明源头已坏，重导 CSV - 导出时务必用「纯文本编辑器」或程序生成（如 PHP 的
fputcsv()），避开 Excel
字段类型声明和字符集必须同步生效
即使表结构正确，导入时若没指定字符集，MySQL 可能用默认 latin1 解析数字字段，导致高位字节错乱；更隐蔽的是，phpMyAdmin 导入页的「字符集」下拉框选了 utf8mb4，但目标字段的 COLLATION 仍是 latin1_swedish_ci，此时数字虽不乱码，但隐式转换可能触发精度降级。
- 导入前执行
ALTER TABLE your_table MODIFY COLUMN id BIGINT UNSIGNED;确保字段定义干净 - 导入页「字符集」选
utf8mb4，同时确认该字段SHOW FULL COLUMNS FROM your_table中的Collation列也是utf8mb4_* - 避免用
LOAD DATA INFILE自动类型推断——它比 INSERT 更容易把长数字当 float 处理
最易被忽略的一点：精度丢失往往不报错、不中断导入，数据看起来“成功插入”，但关键 ID 已不可逆损坏。上线前必须抽样比对原始 CSV 和数据库 SELECT 出来的值，尤其检查末尾 3–4 位数字。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
