作为BI工程师，对SQL的熟练掌握必不可少，greenplum作为MPP数据库，当然需要深入了解一些重要的开发技巧。
日常SQL开发规范要求：
1.代码行清晰、整齐、层次分明、结构性强，易于阅读；
2.代码中应具备必要的注释以增强代码的可读性和可维护性；
3.代码应充分考虑执行效率，保证代码的高效性；
Greenplum数据字典使用,有个重要的schema,分别是：pg_catalog,pg_toolkit,information_schema
information_schema存储数据字典的视图。
| 编号 | 查询主题 | 查询脚本 |
|---|---|---|
| 1 | 查看greenplum资源队列状况 | SELECT * FROM gp_toolkit.gp_resqueue_status; |
| 2 | 查看资源队列中的锁状况 | SELECT * FROM gp_toolkit.gp_locks_on_resqueue WHERE lorwaiting='true'; |
| 3 | 查看当前处于活动状态或者等待状态的语句 |
SELECT rolname, rsqname, pid, granted, current_query, datname FROM pg_roles, gp_toolkit.gp_resqueue_status, pg_locks, pg_stat_activity WHERE pg_roles.rolresqueue=pg_locks.objid AND pg_locks.objid=gp_toolkit.gp_resqueue_status.queueid AND pg_stat_activity.procpid=pg_locks.pid; |
| 4 | 清理语句的进程ID（pid） | Select pg_cancel_backend(pid)； |
| 5 | 查看某账号下运行中sql | SELECT * from pg_stat_activity where current_query <> '<IDLE>' and waiting ='f' and usename = 'user_name'; |
| 6 | 查看等待中的SQL | SELECT * from pg_stat_activity where current_query <> '<IDLE>' and waiting ='t'; |
| 7 | 查看执行时间超长SQL | select * from pg_stat_activity where current_query<>'<IDLE>' and query_start < now() - interval '100 mins'; |
| 编号 | 查询主题 | 查询脚本 | 备注 |
|---|---|---|---|
| 1 | 执行计划（执行SQL前） | explain SQL |
如果执行计划存在针对很大的表做Broadcast Motion 或Nested Loop步骤则 不合理， 则尝试以下动作： 执行收集表的统计信息语句：ANALYZE 表名; 一般analyze 一天的分区: ANALYZE 表名_1_prt_data_part_20150305; “_1_prt_”是数据库分区表名固定段。 “data_part_”是我们自动脚本里生成的分区名前缀。 重新看执行计划，如果合理了，则代表源表缺少统计信息导致执行计划不合理。 只有在表的数据量发生大变化时或重来没收集过时需要做一次收集。 ANALYZE完源表重新看执行计划，如果还不合理，执行一下set optimizer to on； 更换一个执行计划生成器。 重新生成执行计划。如果合理了，则后续在在ＳＱＬ前加上：set optimizer to on； 不要所有SQL加这个，因为该特性未发布。 如果还不合理， 则需要优化SQL， 即把ＳＱＬ由多张表关联拆开 |