Access导入时字段类型映射不准，需手动将MEMO字段映射为TEXT等长文本类型；中文乱码需设GBK字符集并移除方括号；大表应导出CSV绕过ODBC；主键索引等结构需人工补建。
Access导入时字段类型自动映射不准怎么办
navicat 导入 access（.mdb/.accdb）时，text 字段常被映射成 varchar(255)，但 access 里实际可能是 memo（对应长文本），而 navicat 默认不识别该语义，直接截断或报错。
根本原因是 Access 的 ODBC 驱动对字段类型的描述粒度粗，Navicat 依赖驱动返回的 SQL_DESC_TYPE，而非实际内容长度或属性标记。
- 导入前先在 Access 中打开表设计视图，确认
Text字段的「字段大小」是否设为「文本」（≤255）还是「备注」（即 MEMO） - 若含 MEMO 字段，在 Navicat 导入向导的「字段映射」页，手动将对应列的目标类型改为
TEXT或MEDIUMTEXT（MySQL）/TEXT（PostgreSQL） - 避免勾选「自动调整字段长度」——它只看样本行，对空值多或首行短的 MEMO 字段极不可靠
导入后中文乱码或字段名带方括号怎么处理
Access 表名、字段名含空格或特殊字符时，Jet/ACE 驱动会用方括号包裹，如 [客户姓名]；Navicat 直接照搬，导致目标库中字段名含非法字符（尤其 MySQL 8.0+ 默认拒绝方括号）。
更隐蔽的问题是编码：Access 文件本身无明确编码声明，ODBC 驱动常按系统区域设置（如 GBK）读取，而 Navicat 默认以 UTF-8 解析元数据，造成字段名乱码。
- 在 Navicat「导入向导 → 高级设置」中，把「字符集」显式设为
GBK（Windows 简体中文环境）或UTF-8（若 Access 是从其他平台导出且确认 UTF-8 存储） - 勾选「移除标识符括号」（Remove identifier brackets），让
[订单日期]变成订单日期 - 若仍出现乱码，临时改 Windows 系统区域设置为「中文（简体，中国）」再重试——这是 ACE 驱动底层行为，非 Navicat 可配置项
大表导入卡死或内存溢出的绕过方法
Access 单表超 5 万行时，Navicat 默认用 ODBC 的 SQLFetch 逐行拉取，驱动层缓存全量结果集，极易触发内存不足（尤其 32 位 Navicat 或低配机器）。
将 WCAG 2 AA 无障碍标准应用于设计系统、UI 组件和网页——通过可运行的验证器进行对比度计算，采用设计 token 模式使颜色天生可访问，设定排版和焦点状态规则，并提供语义检查清单。适用于构建或审查 UI。
这不是 Navicat Bug，而是 Microsoft ACE OLE DB Provider 对大数据量的固有缺陷：它不支持服务器端游标分页，也不暴露流式读取接口。
- 拆分 Access 表：用 Access 自身查询导出为多个子表（如按时间分段），再分别导入
- 改用中间格式：在 Access 中另存为
CSV（注意选择「UTF-8 编码」和「引号包围文本」），再用 Navicat 导入 CSV——跳过 ODBC 层，性能提升 3–5 倍 - 禁用 Navicat 的「预览数据」和「校验约束」选项，这两项会在导入前全量加载并解析，对大表是纯负担
主键、索引、默认值这些结构信息丢了吗
Navicat 的 Access 导入默认只导数据，不解析表结构定义中的主键、索引、默认值、有效性规则等——这些元信息不在 ODBC 标准接口返回范围内，ACE 驱动未实现 SQLStatistics 或 SQLGetTypeInfo 的完整支持。
换句话说：你看到的「导入成功」只是数据进去了，原 Access 表的约束逻辑全部丢失，后续需人工补建。
- 导入前，在 Access 中执行
SELECT MSysObjects.Name, MSysIndexes.* FROM MSysObjects INNER JOIN MSysIndexes ON MSysObjects.Id = MSysIndexes.Id（需开启系统表显示），手动记录主键和索引字段 - 导入完成后，在目标库中用
ALTER TABLE ... ADD PRIMARY KEY和CREATE INDEX补结构 - 默认值若为函数（如
Now()），无法直接迁移，得改成目标库对应语法（如 MySQL 的CURRENT_TIMESTAMP）
真正麻烦的不是操作步骤，而是 Access 里那些嵌套在查询里的计算字段、查阅向导绑定的下拉值——这些 Navicat 完全不识别，必须对照原始 Access 查询 SQL 手动重写。
