作爲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， 即把ＳＱＬ由多張表關聯拆開 |