根本原因是phpMyAdmin底层用LOAD DATA INFILE只认YYYY-MM-DD或YYYYMMDD格式，不支持STR_TO_DATE()，且按字段顺序而非名称映射，非标准日期被静默置为0000-00-00或丢弃。
phpmyadmin 导入 csv 后日期列显示为 0000-00-00 或直接变空，根本原因不是“格式错了”，而是它压根没把那串字符串识别成日期——load data infile（phpmyadmin 底层用的就是这个）只接受严格符合 yyyy-mm-dd 或 yyyymmdd 的值，其他如 2023/05/12、12-may-2023、2023-05-12 14:30:00 全部被当无效值处理。
phpMyAdmin 不支持 STR_TO_DATE()，导入时无法做格式转换
和 MySQL 命令行不同，phpMyAdmin 的 CSV 导入界面不提供 SET 子句入口，也没法写 STR_TO_DATE(@date_str, '%Y/%m/%d')。它只是把 CSV 每一行原样按字段顺序塞进表里，遇到非标准日期字符串就静默填 0000-00-00（MySQL 严格模式下）或报错中断（取决于 SQL mode）。
- 你看到的“导入成功”可能只是行数统计对了，但日期列实际全崩了
- 即使 CSV 里写的是
2023-05-12，如果目标字段是DATETIME而你给的只有日期部分，MySQL 也会补00:00:00—— 这不算错，但容易误判为失败 - phpMyAdmin 不会校验字段类型兼容性：目标列是
INT，你塞进去"2023-05-12"，它照样转成2023插进去（截断），日期列同理
日期列为空？先检查这三处硬性条件
即使原始数据格式看起来没问题，以下任一条件不满足，日期列都会丢或变 0000-00-00：
- 目标字段类型不是
DATE、DATETIME或TIMESTAMP，而是VARCHAR或TEXT—— phpMyAdmin 不会尝试隐式转换 - CSV 中该列存在空字符串
""、\N（MySQL NULL 标记）、N/A、全零日期0000-00-00，而表结构又设了NOT NULL，MySQL 就拒收整行 - 文件编码不是 UTF-8 无 BOM：BOM 头会让第一列偏移，导致日期列实际被映射到错误字段上，看着像“空”，其实是塞错位置了
绕过 phpMyAdmin 限制的实操路径
别在界面上硬扛，直接换更可控的方式：
QuickBooks Mileage CSV
下载
使用 qbo-mileage CLI 及用户凭证，从 Airtable、Outlook 或 Google Calendar 记录生成 QuickBooks Online 里程 CSV 文件。
- 用
pandas.read_csv()加parse_dates和date_parser=lambda x: pd.to_datetime(x, errors='coerce')在内存中统一转成datetime64[ns]，再用to_sql(dtype={'order_date': sqlalchemy.types.DATE})写入 —— 类型和格式全由 Python 控制 - 导出清洗后的 CSV（确保日期列已是
2023-05-12格式），再用命令行执行：mysql -u user db_name -e "LOAD DATA INFILE '/path/to/clean.csv' INTO TABLE orders FIELDS TERMINATED BY ',' SET order_date = STR_TO_DATE(@date_str, '%Y-%m-%d');" - 如果必须用 phpMyAdmin，先把 CSV 用
sed或awk预处理：比如日期在第 3 列且是DD/MM/YYYY，运行awk -F, -v OFS=, '{$3 = sprintf("%s-%s-%s", $3, $2, $1); print}' input.csv > clean.csv（注意：真实场景需先切分引号包裹字段，推荐用mlr）
最常被忽略的一点：phpMyAdmin 的导入逻辑是“字段顺序对齐”，不是“字段名匹配”。哪怕你 CSV 第一列叫 order_date，只要目标表第一列是 id INT，那一整列日期字符串就会被强行 cast 成整数——这时候看到的不是空，而是莫名其妙的数字，排查方向会彻底跑偏。
立即学习“PHP免费学习笔记（深入）”；
