Ctrl+G是唯一能直接跳转到函数/视图定义物理行号的方式，因其基于真实行号精准定位，不受折叠、注释、空行或编码BOM干扰，输入纯数字回车即瞬时抵达，行号从1起始且需避免空格与非法字符。
Ctrl+G 是唯一能直接跳转到函数/视图定义物理行号的方式
Navicat 的 SQL 编辑器不提供「跳转到定义」（Go to Definition）这类 IDE 级语义导航功能，它只认物理行号。当你在编辑一个包含多个 CREATE FUNCTION、CREATE VIEW 的长脚本时，想快速定位某个函数体开头，最稳的方法就是用 Ctrl+G 输入已知行号——比如你刚复制了 CREATE FUNCTION calc_total 所在行是第 42 行，输 42 回车，光标立刻停在该行首，不依赖折叠状态、不误判注释块、不被空行干扰。
如何提前知道函数或视图在脚本里的行号
靠人眼数行号不现实，得借助外部线索：
- 执行报错提示的行号：MySQL 报
ERROR 1064 at line 89，说明语法错误在第 89 行附近，大概率是函数定义中途少了个END或括号没闭合，Ctrl+G输入89后向上翻几行就能看到CREATE FUNCTION开头 - 搜索结果的行号偏移：先按
Ctrl+F搜CREATE FUNCTION my_func，找到匹配项后，看编辑器左侧行号栏显示的数字（注意不是搜索面板里“第 X 个匹配”），那个就是真实物理行号 - 格式化后重算：如果脚本粘贴进来换行符混乱（
\r\n和\n混用），行号可能错位，先按Ctrl+Shift+F格式化一次，再搜再记行号
为什么不能用「查找对象」跳转到编辑器里的定义
Navicat 的「查找对象」（右键数据库 → 查找对象）只扫描数据库元数据，不会定位你当前编辑器中写的 DDL 脚本。它返回的是服务器上已存在的函数/视图列表和创建语句位置（如存储过程定义），但那个位置指向的是数据库系统表，不是你本地 SQL 文件里的某一行。所以：
- 你在编辑器里写了一段未保存的
CREATE VIEW v_report AS ...，「查找对象」根本看不到它 - 即使你已执行过该语句，「查找对象」查到的是服务器端的定义，点进去打开的是只读的「查看定义」窗口，不是你原始编辑器里的可编辑位置
- 它不返回行号，只给对象类型+名称+所属 schema，无法反向映射回你的脚本坐标
容易忽略的三个跳转失败原因
Ctrl+G 看似简单，但以下细节常导致跳转失败：
- 输入框里有空格：输
87或87，Navicat 会静默当作非法输入，跳到第 1 行；必须输纯数字87 - 行号从 1 开始：不存在第 0 行，输
0不报错，但结果是跳到第 1 行，容易误以为功能失效 - 脚本含隐藏 BOM 或混合编码：UTF-8 with BOM 文件开头的不可见字节会被计入第 1 行，导致所有后续行号 +1；遇到这种情况，用文本编辑器另存为 UTF-8（无 BOM）再重新打开
真正卡住人的不是找不到快捷键，而是调试时盯着报错信息下意识去滚动找，却忘了那个弹出的 Ctrl+G 输入框里该填什么——尤其当行号超过 200 时，滚动十几次比敲三个数字慢得多。
