phpMyAdmin只导入部分SQL数据是因为MySQL执行遇错即停，常见原因包括max_allowed_packet过小、Nginx client_max_body_size拦截、外键顺序错乱或未选目标库；需检查报错详情、确认参数配置并优先使用命令行导入。
phpmyadmin 只导入部分 sql 数据，基本可以断定是执行中途被中断——不是它“选择性导入”，而是 mysql 在某条语句上报错后直接停了，后续所有语句再没机会运行。
为什么卡在第一条错误就停止执行
phpMyAdmin 底层调用的是标准 MySQL 客户端协议，执行 SQL 文件时默认行为是「遇错即停」。它不会自动加 INSERT IGNORE，也不解析注释里的控制指令（比如 --force 或 /* skip */），更不支持跳过重复主键或忽略建表失败。
- 典型表现：进度条卡在 1%，页面弹出红色错误框，只看到前几行数据写入成功
- 常见错误号：
#1062 Duplicate entry '1' for key 'PRIMARY'、#1050 Table 'xxx' already exists、#1153 Got a packet bigger than 'max_allowed_packet' bytes - 即使你勾选了「忽略插入错误」，它只对
INSERT类语句生效，对CREATE TABLE、ALTER TABLE等 DDL 语句完全无效
最常被忽略的三类中断源头
很多人盯着 SQL 内容改来改去，却漏掉了真正拦路的底层限制：
-
max_allowed_packet太小：MySQL 服务端默认常为 4M（5.7）或 64M（8.0+），但一条含大 JSON 或 Base64 的INSERT就可能超限；仅调 PHP 的upload_max_filesize没用，必须同步改 MySQL 配置并重启服务 - Nginx 的
client_max_body_size拦截：宝塔等环境默认 100M，若 SQL 文件 200MB，请求根本到不了 PHP 层，浏览器直接报 413 或空白页 - 外键顺序错乱：SQL 文件里先
INSERT INTO order_items，后INSERT INTO orders，而目标库已启用外键检查（FOREIGN_KEY_CHECKS = 1），第二条就会失败并中断
怎么确认到底卡在哪一句
别靠猜。导入失败后点 phpMyAdmin 页面右下角的「显示详细错误信息」，看完整报错内容；再登录 MySQL 命令行，手动执行以下命令定位问题：
SHOW VARIABLES LIKE 'max_allowed_packet';<br>SELECT VERSION();<br>SHOW CREATE TABLE your_table_name;
- 如果错误含
Unknown collation: 'utf8mb4_0900_as_cs'，说明 SQL 来自 MySQL 8.0+，但目标库是 5.7 或更老版本 - 如果错误是
#1046 No database selected，说明你没在左侧数据库列表里点击目标库就点了「导入」 - 如果导入后行数明显少于预期，且没报错，大概率是 SQL 文件里混着
SET FOREIGN_KEY_CHECKS=0但结尾没恢复，导致部分INSERT被静默丢弃
真正有效的绕过方式只有两种
一种是让 SQL 文件本身适配目标环境，另一种是彻底绕过 phpMyAdmin 的上传执行链：
立即学习“PHP免费学习笔记（深入）”；
- 结构与数据分离：删掉 SQL 文件里的所有
CREATE TABLE和DROP TABLE，只留INSERT、UPDATE；先确保表结构已存在且兼容，再导入纯数据 - 改用命令行导入：
/www/server/mysql/bin/mysql -u root -p --max-allowed-packet=512M your_db_name < /path/to/data.sql—— 它不受 PHP 上传限制、不切片、不依赖 web server，失败时也会明确告诉你哪一行出错
最容易被忽略的一点：很多 SQL 文件开头有 CREATE DATABASE 或 USE other_db，导致后续所有操作落在错误库上，你以为导入失败，其实是数据全跑去了另一个空库。导入前务必打开文件扫一眼前 20 行。
