Navicat导出时tinyint(1)字段显示为0/1，是因为JDBC驱动默认将tinyint(1)映射为Boolean，Navicat再将其标准化为数值字面量；MySQL本身无原生BOOLEAN类型，tinyint(1)本质是整数，括号中1仅为显示宽度，不影响存储范围。
Navicat 本身不会主动把 True/False 转成 0/1 —— 它只是忠实地导出数据库里实际存储的值。真正发生转换的环节，通常在查询执行前或数据读取时，源头是 MySQL 的字段类型定义 + JDBC 驱动行为。
MySQL 中 tinyint(1) 被 JDBC 当作布尔类型处理
这是最常见、也最容易被误认为是 Navicat “搞错”的原因：
- 当你在 MySQL 中建表用的是
TINYINT(1)（比如is_active TINYINT(1)），JDBC 驱动（如 mysql-connector-java）默认会把它映射为 Java 的Boolean类型 - Navicat 底层用 JDBC 连接 MySQL，所以查询结果里这个字段的值已经是
true或false（Java 层面） - 但 Navicat 导出时，对布尔值的默认文本表示就是
1和0（不是字符串"true"/"false"，也不是大写TRUE/FALSE） - 这和导出格式无关（CSV/XLSX/SQL 都一样），是它对 JDBC 返回的
Boolean值做的标准化文本转换
导出 SQL 文件时，INSERT 语句里的布尔字面量被转成 0/1
如果你导出的是 SQL 格式（.sql 文件），且原字段是 TINYINT(1)，那么生成的 INSERT 语句中对应值几乎总是 0 或 1：
- 因为 JDBC 从结果集读取
Boolean后，Navicat 在拼 SQL 字面量时，直接写0和1（符合 MySQL 语法，也兼容所有版本） - 它不会写
TRUE/FALSE，因为 MySQL 的TRUE/FALSE只是别名，底层仍是整数；且低版本（如 5.7）不保证解析稳定 - 即使你手动改表结构为
BOOLEAN或BOOL，MySQL 内部仍等价于TINYINT(1)，驱动行为不变
怎么确认是不是这个原因？
快速验证三步法：
- 在 Navicat 查询窗口执行：
SELECT COLUMN_TYPE FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME = 'your_table' AND COLUMN_NAME = 'your_flag_col';—— 看返回是不是tinyint(1) - 右键表 →「对象信息」→「列」页，检查该字段的数据类型
- 换一个非
TINYINT(1)的字段测试（比如TINYINT(2)或SMALLINT），导出后看是否还是0/1—— 如果变成数字，就坐实了是驱动对(1)的特殊处理
想导出 true/false 文本？基本不可行，也不建议
Navicat 没提供开关把布尔值导成字符串 "true"。强行绕过会有副作用：
- 导出 CSV/XLSX：只能靠 SQL 层转换，例如
SELECT IF(is_active, 'true', 'false') AS is_active ...，但导出后字段类型变成字符串，前端或下游系统可能无法直接当布尔用 - 导出 SQL：写
IF(...)会让 INSERT 变成函数调用，丧失可读性和导入兼容性 - 真正需要语义化布尔输出的场景（如 API 响应），应该由应用层（MyBatis、Spring Data JPA）控制序列化逻辑，而不是依赖 Navicat 导出
最干净的做法，是接受 0/1 就是 MySQL 布尔事实的文本表达，并确保下游系统按整数解释——毕竟连 MySQL 自己的 SELECT TRUE; 返回的也是 1。
