ctrl+g是唯一能精准跳转到指定行号的方式，因其基于物理行计数（含空行、注释行），不受逻辑行干扰；输入纯数字（如87）回车即跳，行号从1起，输0或含空格则静默跳至第1行。
ctrl+g 是唯一能精准跳转到指定行号的方式，其他操作在复杂 sql 中极易误判。
为什么 Ctrl+G 比滚动/查找更可靠
Navicat 的行号显示是物理行计数（含空行、注释行、换行符），而人眼识别的“逻辑行”常被缩进、子查询换行、多语句分隔符（;）干扰。比如一个嵌套 4 层的 SELECT 占了 30 行，你记得条件在“第 12 行附近”，手动滚动很容易跳过；但 Ctrl+G 输入 12 就能稳稳停在那行开头。
常见失效场景：
-
Ctrl+F搜WHERE，结果匹配到注释里的-- WHERE clause is optional - 按
End想到行尾，却因末尾有空格或不可见字符卡住 - 双击单词后按
F3查下一个，光标已不在原位置，跳偏
Ctrl+G 的实际输入规则和易错点
输入框里必须是纯数字，且不能带空格或符号：
- 输
87→ 跳到第 87 行；输87或87→ 静默跳到第 1 行 - 行号从
1开始，没有第 0 行；输0不报错，但直接跳到第 1 行 - 若 SQL 是从外部粘贴进来，混用了
\r\n和\n，行号可能错位——此时先执行Ctrl+Shift+F格式化，再用Ctrl+G
哪些场景下必须用 Ctrl+G
这不是“备用方案”，而是调试和协作中的高频刚需：
- 同事说“第 87 行语法错”，
Ctrl+G→87→回车，1 秒到位 - MySQL 报错
Error at line 234（来自ERROR 1064），立刻跳过去看是不是少逗号或括号没闭合 -
EXPLAIN显示某条SELECT扫描了 50 万行，想快速定位该语句起始位置：记下当前行号，Ctrl+G往前跳 10 行看上下文
真正难的不是记住快捷键，而是把「看到报错行号 → 手指自动按下 Ctrl+G」变成肌肉记忆。很多人花两分钟滚动找，其实 1 秒就能跳到位——只是忘了那个弹出框里该填什么。
