Navicat导入Excel字段映射错乱需手动拖拽对齐列名，确保Excel首行为纯英文字段名；LOAD DATA INFILE受secure_file_priv限制，须查路径并用正斜杠；Python导入大Excel应转CSV+分块读取+指定dtype；中文乱码需UTF-8无BOM编码及utf8mb4字符集；主键冲突默认静默跳过，需选“更新现有记录”。
Navicat 导入 Excel 时字段映射错乱怎么办
Navicat 的 Excel 导入向导默认按列顺序硬匹配，不校验字段名，极易把“姓名”塞进 age 字段、把日期当字符串处理。关键不是点“下一步”快，而是卡在第 4 步的「字段映射」界面必须手动拖拽对齐。
- 导入前确保 Excel 第一行是纯英文字段名（如
user_id、created_at），不能含空格或中文括号 - 进入映射页后，左侧是 Excel 列（
Column 1、Column 2…），右侧是目标表字段（id、name…），必须逐个用鼠标拖动连接，不能依赖自动识别 - 若目标表有
id主键且 Excel 无对应列，右侧勾选id后，左侧留空——Navicat 会自动跳过该字段，由 MySQL 自增填充 - 时间列（如
2024/05/01）在映射时右下角需点开「类型」下拉菜单，显式选DATETIME，否则默认存为VARCHAR
LOAD DATA INFILE 导入 CSV 为什么报错 “Secure File Priv”
LOAD DATA INFILE 是 MySQL 原生命令，速度快但受安全限制：默认只允许读取 secure_file_priv 配置目录下的文件，直接写本地路径（如 'C:/data.csv'）必然失败。
- 先执行
SHOW VARIABLES LIKE 'secure_file_priv';查看允许路径，常见返回值是/var/lib/mysql-files/（Linux）或C:\ProgramData\MySQL\MySQL Server 8.0\Uploads\（Windows） - Excel 必须另存为 UTF-8 编码的 CSV，且首行必须是字段名；用记事本打开确认无 BOM 头（BOM 会导致第一列乱码）
- 命令中路径用正斜杠，且必须省略盘符：正确写法是
LOAD DATA INFILE '/var/lib/mysql-files/data.csv' ...，而非'C:/data.csv' - 如果非要从任意路径读，需修改 MySQL 配置文件
my.cnf，添加secure_file_priv=''并重启服务——但生产环境严禁这么做
Python 脚本导入大 Excel 文件内存爆掉怎么破
用 pandas.read_excel() 直接读百万行 Excel，Python 进程常吃光 8GB 内存然后崩溃。根本问题在于 Excel 格式（.xlsx）是压缩 XML，pandas 解压+解析开销极大。
- 优先转成 CSV：用 Excel「另存为」→「CSV UTF-8」，再用
pandas.read_csv()，内存占用降为 1/5 - 分块读取：对超大 CSV，加参数
chunksize=10000，循环调用to_sql()插入，避免单次加载全量数据 - 关闭索引插入：
to_sql(..., index=False)，否则 pandas 会额外生成一列index，导致字段数不匹配 - 指定 dtype：对数字列强制
dtype={'age': 'Int64'}（注意大写 I），避免 pandas 把空单元格识别为float64然后写入 MySQL 时报类型错误
中文乱码和主键冲突是最容易被忽略的两个坑
前者让“张三”变“å¼ ä¸”，后者让导入中途停在第 127 行——表面成功，实际只写入了部分数据。
- Excel 保存 CSV 时必须选「UTF-8 with BOM」（Windows 记事本选项）或「UTF-8 without BOM」（VS Code），用 Excel 自带「另存为 CSV」会默认 ANSI 编码，中文必乱
- 目标表建表语句里，所有
VARCHAR字段必须显式声明CHARSET=utf8mb4，仅靠数据库默认字符集不够，例如：name VARCHAR(50) CHARSET=utf8mb4 - 主键冲突不会报错中断，而是静默跳过——Navicat 默认模式是「插入新记录」，遇到重复
PRIMARY KEY直接丢弃整行。如需覆盖，导入向导第 5 步要选「更新现有记录」并勾选主键字段
