Navicat 17 表设计搜索框仅支持字段名前缀匹配，不拆分下划线、不支持通配符；输“user”可匹配 username、user_id，但输“id”无法匹配 user_id；需确保光标在框内、字段已保存、避免中文及特殊符号命名。
Navicat 17 设计表顶部搜索框只认前缀，输“user”找不到 user_id
设计表界面顶部那个放大镜图标旁的搜索框，不是模糊搜索，它只做**字段名前缀匹配**。输 user，能命中 username、user_id；但输 id，不会匹配到 user_id 或 order_id——它不拆分下划线，也不支持通配符。
常见错误现象：输完没反应，大概率是焦点没进框里。点击放大镜图标或直接单击框体，确保光标在内；另外，新建字段未点保存前，它不会出现在搜索索引中。
容易被忽略的细节：
- 字段名含空格或反引号（如
`is_deleted`）时，搜索框只认裸名is_deleted - 中文字段名（如 创建时间）支持不稳定，建议统一用英文命名
- 搜索不区分大小写，但对下划线敏感：输
pay可跳到payment_id，但输payid就失效
Ctrl+F 在编辑表里搜字段标题，但只查当前可见列
按 Ctrl+F 打开查找框后，默认是“查找数据”，得手动切换成“查找列”，再从下拉列表选目标字段——但它只在**当前屏幕显示的列范围内**搜索，滚动后没加载的字段根本不在检索范围里。
这个操作适合快速确认某字段是否已出现在当前视图，但不能替代结构层面的定位。比如你怀疑 tmp_flag 是否还存在，但该字段在第 23 列，而当前只看到前 10 列，Ctrl+F 就搜不到。
使用场景有限：
- 字段数少（≤15）、且你记得大致位置时，可辅助验证
- 配合“排序”用：右键字段列表 → Sort Columns → 按 Name 排序，让所有字段按字母序排列，再
Ctrl+F查更可靠 - 它不查字段类型、默认值、索引状态等元信息，纯 UI 层文本匹配
删冗余字段前，必须先查依赖，Navicat 不提示外键和索引
点红色减号删字段前，Navicat 绝不会弹窗告诉你：“这个字段正被联合索引 idx_user_status 引用”。它把字段删了，但索引还在，后续执行 ALTER TABLE 就会报错 #1025。
实操建议：
- 删字段前，先执行：
SHOW INDEX FROM `table_name` WHERE Column_name = 'old_field' - 查外键：
SELECT CONSTRAINT_NAME FROM information_schema.KEY_COLUMN_USAGE WHERE TABLE_NAME='table_name' AND COLUMN_NAME='old_field' - 查视图/存储过程：
SELECT * FROM information_schema.VIEWS WHERE VIEW_DEFINITION LIKE '%old_field%' - Navicat 的“生成 SQL”按钮一定要点——预览它准备执行的语句，确认是
DROP COLUMN而非误改类型
参数差异：MySQL 支持一条语句删多个字段（DROP COLUMN a, DROP COLUMN b），PostgreSQL 必须分两条写；Navicat 图形界面不支持批量删，只能手写 SQL。
真正高效定位冗余字段，靠导出 DDL + 外部工具全文搜索
几十张表、上百字段要筛查冗余，靠设计表界面逐个点开效率太低。最稳的路径是：右键数据库 → Schema Sync → Generate SQL → 保存为 schema.sql，然后用 VS Code 或 Sublime Text 打开，Ctrl+F 全局搜 temp_、backup_、old_ 这类命名特征。
这样能一眼看出哪些字段在多张表里重复出现、哪些字段定义为空但没被删、哪些字段类型明显异常（如 VARCHAR(500) 存时间戳）。
容易被忽略的点：
- Navicat 表设计器键盘导航（打字跳转）对带下划线的长字段名最有效：输
p→pa→pay，比滚动快得多 - 字段名含中文或特殊符号时，键盘导航可能失效，此时只能靠导出 DDL 后搜索
- 删字段后应用报错
Unknown column 'xxx'，说明代码里还硬编码着字段名——Navicat 不管 ORM 层，得自己 grepping 项目源码
