很多DBA和开发同学刚接触GBase 8c时习惯把gsql当成一个“能执行SQL的输入框”敲完SQL看一眼结果就完事。但真到排查慢SQL、给开发导数据、或者把几十个节点的巡检脚本串起来跑的时候才会发现真正让gsql好用到飞起的是那堆以反斜杠开头的元命令。上一篇我整理了\dt、\di、\l这几个最基础的“查字典”命令算是把底子打好了。这一篇接着往下挖聚焦四个在日常工作中出现频率极高、但大多数人没真正玩明白的方向输出格式控制、对象信息核查、变量与脚本自动化、执行时序统计。每一块都会给出可以直接复制跑的示例还会把那些官方文档里翻不到、但实际一踩一个准的坑先替你踩一遍。1. 输出格式类元命令把查询结果变得能看、能存、能交差1.1 \pset的完整拆解表格边框、对齐方式与空值显示先聊\pset。这个命令控制的是gsql客户端的“渲染层”它不改数据库里任何数据纯粹管结果怎么显示。很多人在终端里看到一张挤成一团的表就以为数据有问题其实只是没调对参数。\pset最常用的三个参数是border、format和null\pset border 2 \pset null NULL \pset footer offborder取值0、1、2。0表示无边框1表示只有行分隔线2表示完整方框线。日常人眼阅读建议用2输出结构最清晰。null设置空值显示为指定字符串。默认空值在结果里就是一坨空白很容易和后边的空格混淆改成NULL之后一眼就能看出哪些字段是真空的。footer控制是否显示结果行数统计。如果你要拿结果喂给后续脚本处理建议off少一行噪音。如果字段本身很长还可以用别的format。我把几种常用format的效果整理了一下format取值适用场景特点aligned默认人眼阅读自动对齐各列观感最佳unalignedshell/awk处理字段用分隔符拼接无额外填充空格csv交接给Excel/数仓标准逗号分隔注意字段内逗号需转义wrapped终端宽度不够时会折行显示尽量少出横向滚动条实际执行效果大概是这样的border 2加null设置后一张普通表就变得清清楚楚。我习惯把这些配置写进~/.gsqlrc每次进gsql自动生效省事很多。但要注意团队共用同一台服务器时别随便改全局配置免得影响别人习惯。1.2 横向爆表的救星\x扩展显示与auto模式数据库里查一张宽表字段一多一格一格的横向排列就会超出终端宽度结果不是疯狂换行就是横向滚动看着非常痛苦。这时候\x就是救星。\x on会把每一行记录从“横向表格”变成“纵向字段堆叠”\x on SELECT * FROM t_order WHERE order_id 10086;执行后每行记录会按“字段名: 值”的形式一列一列纵向排出来字段再长也不怕挤。这个模式在排查单行大字段、或者看一张几十列的表的具体内容时效率比横向输出高出一大截。更聪明的是\x auto。开启后gsql会自己根据查询结果列数和终端宽度判断——如果横向放得下就用普通表格放不下就自动切成扩展显示。我个人强烈推荐日常会话里直接\x auto因为它既保留了表格的紧凑感又避免了偶尔一条超级宽SQL打乱阅读节奏。如果你既想让字段换行又想保留表格结构可以配合\pset format wrapped用。它会把超宽的列折行输出适合那种“字段不多但每个字段都很长”的场景比如查接口报文表。1.3 结果落盘\o重定向与\copy导出实战终端上看得再好也只是临时的更多时候我们需要把结果存成文件发给开发、留作日志、或者交给定时任务。这时就要用\o。\o /tmp/report.txt SELECT order_id, amount, status FROM t_order WHERE create_time now() - interval 1 day; \o执行完第一条\o之后后面所有查询结果都会追加写入/tmp/report.txt直到你再次执行不带参数的\o恢复屏幕输出。忘关\o是新手最容易犯的错——结果全进文件了终端上一个字都看不到还以为SQL挂了。配合\o常用的是\qecho它专门向输出文件里写一段说明文字适合给报告打标签\o /tmp/order_check.txt \qecho 每日订单巡检报告 \qecho 生成时间: 2024年某月某日 SELECT count(*) FROM t_order WHERE status pending; \o如果目的不只是“保存查询结果”而是要导出数据直接用\copy更专业。\copy是GSql客户端自带的导入导出指令可以把表数据导出为CSV格式文件\copy (SELECT id, name, amount FROM t_order) TO /tmp/order.csv WITH CSV HEADER因为\copy走的是客户端文件系统所以导出路径在你本机不是数据库服务器上。这点和SQL里的COPY TO有本质区别生产环境里权限控制更安全也更适合普通开发人员使用。2. 对象信息核查元命令把数据库“家底”翻个底朝天2.1 快速定位用户、Schema与权限\du、\dn实战排查权限问题是DBA日常最烦的活儿。谁建的表、谁能查、这个schema是谁的靠翻系统表能看但用元命令更快。\dn列出所有schemagbase# \dn 列表方案 public test_schema archive\du列出所有用户和角色gbase# \du 角色列表 角色名称 | 属性 -------------------------------------------- gbase | 超级用户 app_read | 普通用户 etl_user | 普通用户这两个命令单独用信息有限真正干活时要结合“看某个用户到底能碰哪些schema”来查。一种比较实用的组合是先用\du确认用户存在再用SQL去information_schema或pg_user里查它的权限关系。另外GBase 8c的权限模型里还要注意把“用户”和“角色”分开理解某些版本里\du看到的是角色的集合而不是传统意义上的登录账号。我踩过的坑新环境的search_path默认没包含业务schema时直接\dn看得到schema列表但\dt却一张表都看不到。这个不是权限问题是搜索路径问题需要先SET search_path TO test_schema;再继续。2.2 \d家族表、视图、序列、函数逐个击破\d加不同后缀能一眼看穿不同类型对象的结构。这是排查问题最高频的一族命令\d 表名查看表的列、类型、非空约束、默认值、索引、外键等完整结构。\d 表名比\d更详细会显示存储参数、表空间、注释、统计信息相关字段。\df 函数名查函数定义能看参数列表和返回类型。\dv 视图名查看视图信息。\ds 序列名查看序列信息。\dT查看自定义数据类型。我在日常运维里最常用的是\d尤其是排查“为什么这条查询不走索引”时先秒开看一下表上有没有索引比写一长串SQL查pg_indexes直观得多。\d t_order_detail它会清楚列出现有哪些索引、索引字段是什么、是否唯一。对于开发和运维来说这个命令基本替代了“翻建表脚本”的需求哪怕这张表是三年前建的也能快速还原它的结构。2.3 用LIKE与正则过滤器精确定位对象名很多人在生产环境里执行\dt刷出几百张表屏幕直接卡死然后不知所措。记住一个原则元命令都支持模式匹配带着条件查才是正确姿势。模式的语法和LIKE类似*代表任意多个字符?代表单个字符。比如\dt public.t_* \df public.*get_*想查某个schema下所有视图\dv test_schema.*更精细的做法是使用正则表达式用斜杠包裹匹配串\dt /^t_order_\d{4}$/这个能精准过滤出t_order_2024这种四位年份后缀的表。注意元命令的模式匹配大小写规则不带引号时是不区分大小写的需要区分就用双引号把名字包起来。经验总结写自动化巡检脚本时先用\dn确认schema名再用\dt schema.*缩小范围最后才\d 具体表名主键、索引、字段类型、是否有注释一次看清。3. 脚本自动化与变量替换把gsql变成批处理执行引擎3.1 从\set到:var变量定义、引用的正确姿势gsql的元命令支持变量定义这是它从一个“交互工具”升级为“脚本引擎”的关键。\set table_name t_order SELECT * FROM :table_name LIMIT 5;执行时gsql会把:table_name替换成t_order然后发给数据库执行。类似的时间变量、路径变量、阈值变量都可以提前定义好脚本运行时灵活替换。常用的变量操作\set name value定义变量。\set不带参数列出会话中所有变量。\unset name删除变量。:var给变量值加一层SQL字符串引号防止值里的特殊字符搞事。变量替换有三个非常容易踩的坑这里单独说坑一变量未定义时直接替换成空字符串。脚本里拼SQL时一个写错的变量名会导致SQL缺一块报错信息很迷。排查时先执行\set确认变量存在。坑二字符串值不加引号。比如变量值本身是abc你写SELECT :path_var和写SELECT :path_var结果完全不同后者会被当成标识符在数据库里找abc这一列直接语法错误。凡是拼字符串常量必须写成:var。坑三ORDER BY这类位置变量替换后可能带出奇怪语义。变量内容进入SQL前gsql不做任何转义所以外部传入的内容一定要自己校验绝不能让用户的输入直接拼接进变量。3.2 \gset与\gexec把查询结果喂给变量再变成执行语句\set只能手动赋值但更多时候我们希望从数据库里查一个值再把它当变量用。\gset就是干这个的。SELECT count(*) AS tbl_cnt FROM pg_tables WHERE schemaname public; \gset SELECT :tbl_cnt;\gset会把查询结果第一行的列名变成同名变量。比如上面查询返回count列gsql会存成变量tbl_cnt之后就能用:tbl_cnt引用。更刺激的是\gexec。它把当前查询结果的每一行都当成“新的命令”再执行一遍。这个在批量操作里能直接封神SELECT format(ANALYZE %I.%I;, schemaname, relname) AS stmt FROM pg_stat_user_tables WHERE schemaname public AND n_live_tup 0 \gexec这段会查出所有记录数非零的表然后对每张表动态生成一条ANALYZE语句再逐条执行。几十张表的统计信息刷新一行命令搞定。\gexec功能虽强但也很危险。建议正式执行前先把查询本身跑一遍确认生成的语句都是你要的再上。我见过有人把DROP语句拼出来直接\gexec结果瞬间清了一库的测试表——还好是测试环境。生产环境务必谨慎。3.3 条件控制流\if、\elif、\else、\endif实战gsql同样支持条件分支脚本可以做得更像程序。先确认一个阈值条件再做不同处理\set max_tables 100 SELECT count(*) :max_tables AS too_many FROM pg_tables; \if :too_many \echo 表数量超出阈值需要告警 \else \echo 表数量正常 \endif注意\if后面的变量判断是基于“值”的true/false是SQL查询返回的布尔值变量里会存成字符串。只要这个变量值不是空、不是“0”一般都会被理解成真。想更严谨就自己写\if :flag t这类判断。一个典型场景是自动部署脚本里先检查数据库连通状态连不上就直接退出连上了才继续建表、刷数据。这些逻辑纯靠SQL写不出来但元命令可以。条件控制流让gsql脚本具备了“分支决策能力”配合前面讲的变量和\gexec一套简单的自动化巡检、部署、校验工具链就成型了。4. 执行效率与排错技巧让每次执行都看得清、算得准4.1 \timing on统计时间的正确打开方式写SQL想知道效率\timing on是最直接的办法\timing on SELECT count(*) FROM t_order WHERE status completed;执行完终端会自动打印一行“Time: 123.456 ms”。每次查询都自动计时不用自己看着秒表掐。需要理解的是这个时间包括了整个gsql会话的往返开销、数据传输时间、结果渲染时间不只是数据库端的执行耗时。如果你只关心服务端执行计划得配合EXPLAIN ANALYZE看EXPLAIN (ANALYZE, BUFFERS) SELECT count(*) FROM t_order WHERE status completed;这两者怎么配合\timing适合日常“快不快”的直观判断EXPLAIN ANALYZE适合定位“到底慢在哪一步”。有人看到\timing出来的时间长就怀疑数据库慢其实可能是网络延迟高或者结果集大到客户端渲染了半天。4.2 回显与日志输出ECHO、\qecho的分层用法写完自动化脚本最怕啥一出问题不知道它内部到底执行了啥。这时ECHO回显就派上用场了。\set ECHO all开启后gsql会把脚本里每一行SQL原文打印出来后面再跟着结果行。做日志审计时非常直观哪条SQL跑失败了看日志里的SQL回显就知道。\echo和\qecho是有区别的\echo输出到标准输出也就是当前屏幕适合交互提示。\qecho输出到由\o指定的文件里适合给巡检报告写注释行。我常在巡检脚本里这么用\o /tmp/check_report.log \qecho 数据库巡检开始 \timing on SELECT instance ok AS health_status; \qecho 巡检结束 \o跑完把/tmp/check_report.log直接扔给值班的人看执行状态一目了然。这里注意\qecho只有在\o开启时才有效没开\o时它也会输出到屏幕但意义不大。4.3 高频问题速查与排错手记把我在实际使用中遇到的高频问题整理成一张表你们遇到类似情况直接照方抓药现象可能原因解决办法中文显示成乱码客户端字符集和数据库字符集不一致先执行\encoding utf8再用SHOW server_encoding;对比设置查询结果不进文件终端也没输出\o路径写错或权限不足确认路径可写执行不带参数的\o恢复默认输出\dt什么也查不到当前search_path不包含目标schema执行SET search_path TO 目标schema;或用\dt 目标schema.*变量引用后SQL执行报错变量值没加引号被当成列名字符串变量用:var引用必要时先SELECT :var;验证\gexec误删数据拼接的语句没预先审视永远先单独跑一遍SELECT人工确认无DROP/DELETE\timing测出的时间明显偏高包含客户端渲染和网络传输用EXPLAIN ANALYZE检查服务端执行计划脚本执行到一半退出某条SQL报错且gsql默认出错即停脚本开头加\set ON_ERROR_STOP off或逐段排错还要补充一个连接管理小技巧\conninfo可以随时查看当前连的是哪个库、哪个用户、哪个端口排查连错库的经典问题非常有用。\password可以在客户端交互式修改密码不用手工拼ALTER USER语句。一些还想多说的经验我在日常巡检里最常用的组合是\pset null NULL\timing on 按需\x auto不管拍日志还是甩给开发看都足够清晰。还有一个小技巧如果你写了一个gsql脚本要交给别人跑记得在脚本开头加一段初始化片段——\set ECHO all记录输入、\o打开日志、\timing on带上耗时最后\q退出时给个固定结束标志。这样哪怕脚本在半路挂了翻日志也能快速定位是第几步出了问题。还有一点我踩过几次坑之后才长记性凡是脚本里用了:变量拼SQL的地方先单独跑一遍把变量值打出来确认无误再放行整个脚本。一条空变量毁掉一个自动化任务的事听着低级出现频率真不低。gsql这套元命令学透之后你在它里面就不只是“敲SQL”了完全可以把它当成一个轻量级脚本平台来用。后续我再继续整理GBase 8c运维中常用的工具和排查方法欢迎持续关注。
很多DBA和开发同学刚接触GBase 8c时习惯把gsql当成一个“能执行SQL的输入框”敲完SQL看一眼结果就完事。但真到排查慢SQL、给开发导数据、或者把几十个节点的巡检脚本串起来跑的时候才会发现真正让gsql好用到飞起的是那堆以反斜杠开头的元命令。上一篇我整理了\dt、\di、\l这几个最基础的“查字典”命令算是把底子打好了。这一篇接着往下挖聚焦四个在日常工作中出现频率极高、但大多数人没真正玩明白的方向输出格式控制、对象信息核查、变量与脚本自动化、执行时序统计。每一块都会给出可以直接复制跑的示例还会把那些官方文档里翻不到、但实际一踩一个准的坑先替你踩一遍。1. 输出格式类元命令把查询结果变得能看、能存、能交差1.1 \pset的完整拆解表格边框、对齐方式与空值显示先聊\pset。这个命令控制的是gsql客户端的“渲染层”它不改数据库里任何数据纯粹管结果怎么显示。很多人在终端里看到一张挤成一团的表就以为数据有问题其实只是没调对参数。\pset最常用的三个参数是border、format和null\pset border 2 \pset null NULL \pset footer offborder取值0、1、2。0表示无边框1表示只有行分隔线2表示完整方框线。日常人眼阅读建议用2输出结构最清晰。null设置空值显示为指定字符串。默认空值在结果里就是一坨空白很容易和后边的空格混淆改成NULL之后一眼就能看出哪些字段是真空的。footer控制是否显示结果行数统计。如果你要拿结果喂给后续脚本处理建议off少一行噪音。如果字段本身很长还可以用别的format。我把几种常用format的效果整理了一下format取值适用场景特点aligned默认人眼阅读自动对齐各列观感最佳unalignedshell/awk处理字段用分隔符拼接无额外填充空格csv交接给Excel/数仓标准逗号分隔注意字段内逗号需转义wrapped终端宽度不够时会折行显示尽量少出横向滚动条实际执行效果大概是这样的border 2加null设置后一张普通表就变得清清楚楚。我习惯把这些配置写进~/.gsqlrc每次进gsql自动生效省事很多。但要注意团队共用同一台服务器时别随便改全局配置免得影响别人习惯。1.2 横向爆表的救星\x扩展显示与auto模式数据库里查一张宽表字段一多一格一格的横向排列就会超出终端宽度结果不是疯狂换行就是横向滚动看着非常痛苦。这时候\x就是救星。\x on会把每一行记录从“横向表格”变成“纵向字段堆叠”\x on SELECT * FROM t_order WHERE order_id 10086;执行后每行记录会按“字段名: 值”的形式一列一列纵向排出来字段再长也不怕挤。这个模式在排查单行大字段、或者看一张几十列的表的具体内容时效率比横向输出高出一大截。更聪明的是\x auto。开启后gsql会自己根据查询结果列数和终端宽度判断——如果横向放得下就用普通表格放不下就自动切成扩展显示。我个人强烈推荐日常会话里直接\x auto因为它既保留了表格的紧凑感又避免了偶尔一条超级宽SQL打乱阅读节奏。如果你既想让字段换行又想保留表格结构可以配合\pset format wrapped用。它会把超宽的列折行输出适合那种“字段不多但每个字段都很长”的场景比如查接口报文表。1.3 结果落盘\o重定向与\copy导出实战终端上看得再好也只是临时的更多时候我们需要把结果存成文件发给开发、留作日志、或者交给定时任务。这时就要用\o。\o /tmp/report.txt SELECT order_id, amount, status FROM t_order WHERE create_time now() - interval 1 day; \o执行完第一条\o之后后面所有查询结果都会追加写入/tmp/report.txt直到你再次执行不带参数的\o恢复屏幕输出。忘关\o是新手最容易犯的错——结果全进文件了终端上一个字都看不到还以为SQL挂了。配合\o常用的是\qecho它专门向输出文件里写一段说明文字适合给报告打标签\o /tmp/order_check.txt \qecho 每日订单巡检报告 \qecho 生成时间: 2024年某月某日 SELECT count(*) FROM t_order WHERE status pending; \o如果目的不只是“保存查询结果”而是要导出数据直接用\copy更专业。\copy是GSql客户端自带的导入导出指令可以把表数据导出为CSV格式文件\copy (SELECT id, name, amount FROM t_order) TO /tmp/order.csv WITH CSV HEADER因为\copy走的是客户端文件系统所以导出路径在你本机不是数据库服务器上。这点和SQL里的COPY TO有本质区别生产环境里权限控制更安全也更适合普通开发人员使用。2. 对象信息核查元命令把数据库“家底”翻个底朝天2.1 快速定位用户、Schema与权限\du、\dn实战排查权限问题是DBA日常最烦的活儿。谁建的表、谁能查、这个schema是谁的靠翻系统表能看但用元命令更快。\dn列出所有schemagbase# \dn 列表方案 public test_schema archive\du列出所有用户和角色gbase# \du 角色列表 角色名称 | 属性 -------------------------------------------- gbase | 超级用户 app_read | 普通用户 etl_user | 普通用户这两个命令单独用信息有限真正干活时要结合“看某个用户到底能碰哪些schema”来查。一种比较实用的组合是先用\du确认用户存在再用SQL去information_schema或pg_user里查它的权限关系。另外GBase 8c的权限模型里还要注意把“用户”和“角色”分开理解某些版本里\du看到的是角色的集合而不是传统意义上的登录账号。我踩过的坑新环境的search_path默认没包含业务schema时直接\dn看得到schema列表但\dt却一张表都看不到。这个不是权限问题是搜索路径问题需要先SET search_path TO test_schema;再继续。2.2 \d家族表、视图、序列、函数逐个击破\d加不同后缀能一眼看穿不同类型对象的结构。这是排查问题最高频的一族命令\d 表名查看表的列、类型、非空约束、默认值、索引、外键等完整结构。\d 表名比\d更详细会显示存储参数、表空间、注释、统计信息相关字段。\df 函数名查函数定义能看参数列表和返回类型。\dv 视图名查看视图信息。\ds 序列名查看序列信息。\dT查看自定义数据类型。我在日常运维里最常用的是\d尤其是排查“为什么这条查询不走索引”时先秒开看一下表上有没有索引比写一长串SQL查pg_indexes直观得多。\d t_order_detail它会清楚列出现有哪些索引、索引字段是什么、是否唯一。对于开发和运维来说这个命令基本替代了“翻建表脚本”的需求哪怕这张表是三年前建的也能快速还原它的结构。2.3 用LIKE与正则过滤器精确定位对象名很多人在生产环境里执行\dt刷出几百张表屏幕直接卡死然后不知所措。记住一个原则元命令都支持模式匹配带着条件查才是正确姿势。模式的语法和LIKE类似*代表任意多个字符?代表单个字符。比如\dt public.t_* \df public.*get_*想查某个schema下所有视图\dv test_schema.*更精细的做法是使用正则表达式用斜杠包裹匹配串\dt /^t_order_\d{4}$/这个能精准过滤出t_order_2024这种四位年份后缀的表。注意元命令的模式匹配大小写规则不带引号时是不区分大小写的需要区分就用双引号把名字包起来。经验总结写自动化巡检脚本时先用\dn确认schema名再用\dt schema.*缩小范围最后才\d 具体表名主键、索引、字段类型、是否有注释一次看清。3. 脚本自动化与变量替换把gsql变成批处理执行引擎3.1 从\set到:var变量定义、引用的正确姿势gsql的元命令支持变量定义这是它从一个“交互工具”升级为“脚本引擎”的关键。\set table_name t_order SELECT * FROM :table_name LIMIT 5;执行时gsql会把:table_name替换成t_order然后发给数据库执行。类似的时间变量、路径变量、阈值变量都可以提前定义好脚本运行时灵活替换。常用的变量操作\set name value定义变量。\set不带参数列出会话中所有变量。\unset name删除变量。:var给变量值加一层SQL字符串引号防止值里的特殊字符搞事。变量替换有三个非常容易踩的坑这里单独说坑一变量未定义时直接替换成空字符串。脚本里拼SQL时一个写错的变量名会导致SQL缺一块报错信息很迷。排查时先执行\set确认变量存在。坑二字符串值不加引号。比如变量值本身是abc你写SELECT :path_var和写SELECT :path_var结果完全不同后者会被当成标识符在数据库里找abc这一列直接语法错误。凡是拼字符串常量必须写成:var。坑三ORDER BY这类位置变量替换后可能带出奇怪语义。变量内容进入SQL前gsql不做任何转义所以外部传入的内容一定要自己校验绝不能让用户的输入直接拼接进变量。3.2 \gset与\gexec把查询结果喂给变量再变成执行语句\set只能手动赋值但更多时候我们希望从数据库里查一个值再把它当变量用。\gset就是干这个的。SELECT count(*) AS tbl_cnt FROM pg_tables WHERE schemaname public; \gset SELECT :tbl_cnt;\gset会把查询结果第一行的列名变成同名变量。比如上面查询返回count列gsql会存成变量tbl_cnt之后就能用:tbl_cnt引用。更刺激的是\gexec。它把当前查询结果的每一行都当成“新的命令”再执行一遍。这个在批量操作里能直接封神SELECT format(ANALYZE %I.%I;, schemaname, relname) AS stmt FROM pg_stat_user_tables WHERE schemaname public AND n_live_tup 0 \gexec这段会查出所有记录数非零的表然后对每张表动态生成一条ANALYZE语句再逐条执行。几十张表的统计信息刷新一行命令搞定。\gexec功能虽强但也很危险。建议正式执行前先把查询本身跑一遍确认生成的语句都是你要的再上。我见过有人把DROP语句拼出来直接\gexec结果瞬间清了一库的测试表——还好是测试环境。生产环境务必谨慎。3.3 条件控制流\if、\elif、\else、\endif实战gsql同样支持条件分支脚本可以做得更像程序。先确认一个阈值条件再做不同处理\set max_tables 100 SELECT count(*) :max_tables AS too_many FROM pg_tables; \if :too_many \echo 表数量超出阈值需要告警 \else \echo 表数量正常 \endif注意\if后面的变量判断是基于“值”的true/false是SQL查询返回的布尔值变量里会存成字符串。只要这个变量值不是空、不是“0”一般都会被理解成真。想更严谨就自己写\if :flag t这类判断。一个典型场景是自动部署脚本里先检查数据库连通状态连不上就直接退出连上了才继续建表、刷数据。这些逻辑纯靠SQL写不出来但元命令可以。条件控制流让gsql脚本具备了“分支决策能力”配合前面讲的变量和\gexec一套简单的自动化巡检、部署、校验工具链就成型了。4. 执行效率与排错技巧让每次执行都看得清、算得准4.1 \timing on统计时间的正确打开方式写SQL想知道效率\timing on是最直接的办法\timing on SELECT count(*) FROM t_order WHERE status completed;执行完终端会自动打印一行“Time: 123.456 ms”。每次查询都自动计时不用自己看着秒表掐。需要理解的是这个时间包括了整个gsql会话的往返开销、数据传输时间、结果渲染时间不只是数据库端的执行耗时。如果你只关心服务端执行计划得配合EXPLAIN ANALYZE看EXPLAIN (ANALYZE, BUFFERS) SELECT count(*) FROM t_order WHERE status completed;这两者怎么配合\timing适合日常“快不快”的直观判断EXPLAIN ANALYZE适合定位“到底慢在哪一步”。有人看到\timing出来的时间长就怀疑数据库慢其实可能是网络延迟高或者结果集大到客户端渲染了半天。4.2 回显与日志输出ECHO、\qecho的分层用法写完自动化脚本最怕啥一出问题不知道它内部到底执行了啥。这时ECHO回显就派上用场了。\set ECHO all开启后gsql会把脚本里每一行SQL原文打印出来后面再跟着结果行。做日志审计时非常直观哪条SQL跑失败了看日志里的SQL回显就知道。\echo和\qecho是有区别的\echo输出到标准输出也就是当前屏幕适合交互提示。\qecho输出到由\o指定的文件里适合给巡检报告写注释行。我常在巡检脚本里这么用\o /tmp/check_report.log \qecho 数据库巡检开始 \timing on SELECT instance ok AS health_status; \qecho 巡检结束 \o跑完把/tmp/check_report.log直接扔给值班的人看执行状态一目了然。这里注意\qecho只有在\o开启时才有效没开\o时它也会输出到屏幕但意义不大。4.3 高频问题速查与排错手记把我在实际使用中遇到的高频问题整理成一张表你们遇到类似情况直接照方抓药现象可能原因解决办法中文显示成乱码客户端字符集和数据库字符集不一致先执行\encoding utf8再用SHOW server_encoding;对比设置查询结果不进文件终端也没输出\o路径写错或权限不足确认路径可写执行不带参数的\o恢复默认输出\dt什么也查不到当前search_path不包含目标schema执行SET search_path TO 目标schema;或用\dt 目标schema.*变量引用后SQL执行报错变量值没加引号被当成列名字符串变量用:var引用必要时先SELECT :var;验证\gexec误删数据拼接的语句没预先审视永远先单独跑一遍SELECT人工确认无DROP/DELETE\timing测出的时间明显偏高包含客户端渲染和网络传输用EXPLAIN ANALYZE检查服务端执行计划脚本执行到一半退出某条SQL报错且gsql默认出错即停脚本开头加\set ON_ERROR_STOP off或逐段排错还要补充一个连接管理小技巧\conninfo可以随时查看当前连的是哪个库、哪个用户、哪个端口排查连错库的经典问题非常有用。\password可以在客户端交互式修改密码不用手工拼ALTER USER语句。一些还想多说的经验我在日常巡检里最常用的组合是\pset null NULL\timing on 按需\x auto不管拍日志还是甩给开发看都足够清晰。还有一个小技巧如果你写了一个gsql脚本要交给别人跑记得在脚本开头加一段初始化片段——\set ECHO all记录输入、\o打开日志、\timing on带上耗时最后\q退出时给个固定结束标志。这样哪怕脚本在半路挂了翻日志也能快速定位是第几步出了问题。还有一点我踩过几次坑之后才长记性凡是脚本里用了:变量拼SQL的地方先单独跑一遍把变量值打出来确认无误再放行整个脚本。一条空变量毁掉一个自动化任务的事听着低级出现频率真不低。gsql这套元命令学透之后你在它里面就不只是“敲SQL”了完全可以把它当成一个轻量级脚本平台来用。后续我再继续整理GBase 8c运维中常用的工具和排查方法欢迎持续关注。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
