一、为什么需要查询重写插件
在日常数据库使用中，我们经常会遇到一些"顽固"的SQL查询——它们要么性能不佳，要么写法不够优雅。比如开发同学写了个全表扫描的查询，或者业务SQL里藏着N+1查询问题。传统做法是找到开发人员修改代码，但现实情况往往是：老系统不敢乱改、第三方系统无法改、紧急优化等不及发版。
这时候查询重写插件就像个"SQL翻译官"，能在查询到达数据库引擎前悄悄改写SQL。比如把SELECT * FROM users改成SELECT id,name FROM users，或者把隐式JOIN转为显式JOIN。我们团队在使用PolarDB时就经常用它来解决以下问题：
- 给没有limit的查询自动加上分页
- 将OR条件改写为UNION ALL提高效率
- 为特定表自动添加分区条件
二、PolarDB插件开发基础
开发PolarDB插件需要先了解它的Hook机制。PG系的数据库都提供了丰富的Hook点，就像高速公路上的检查站，允许我们在特定环节拦截处理。这里用个简单的示例展示如何注册一个查询重写Hook（技术栈：PostgreSQL 13/PolarDB）：
#include "postgres.h"
#include "tcop/utility.h"
// 声明Hook函数
static QueryRewriteHandlerType original_rewrite_handler = NULL;
static List *my_query_rewriter(Query *query, const char *query_string);
// 模块初始化
void _PG_init(void)
{
// 保存原始Hook并替换成我们的
original_rewrite_handler = GetQueryRewriteHook();
SetQueryRewriteHook(my_query_rewriter);
}
// 实际的重写函数
static List *my_query_rewriter(Query *query, const char *query_string)
{
List *rewritten_queries = NIL;
// 先调用原始重写器（如规则系统）
if (original_rewrite_handler)
rewritten_queries = (*original_rewrite_handler)(query, query_string);
else
rewritten_queries = list_make1(query);
// 这里添加我们的重写逻辑
if (query->commandType == CMD_SELECT) {
// 示例：给所有SELECT加上LIMIT 1000
query->limitCount = makeConst(INT8OID, -1, InvalidOid, sizeof(int64),
Int64GetDatum(1000), false, FLOAT8PASSBYVAL);
}
return rewritten_queries;
}
这个示例展示了最基本的插件结构。实际开发中我们还需要处理更多细节：
- 内存分配要使用palloc/pfree
- 注意查询树的深度拷贝
- 考虑预备语句的执行计划缓存
三、典型重写场景实战
3.1 分页自动优化
电商系统经常遇到深度分页问题，比如SELECT * FROM orders ORDER BY id OFFSET 10000 LIMIT 20。我们可以重写成更高效的写法：
// 在my_query_rewriter函数中添加：
if (query->limitCount && query->limitOffset &&
IsA(query->limitOffset, Const)) {
Const *offset_const = (Const *)query->limitOffset;
int64 offset = DatumGetInt64(offset_const->constvalue);
if (offset > 1000) { // 阈值可根据业务调整
// 重写为：SELECT * FROM orders WHERE id > (SELECT id FROM orders ORDER BY id OFFSET 10000 LIMIT 1) LIMIT 20
// ...具体实现代码约50行...
}
}
3.2 查询条件注入
多租户系统需要自动添加tenant_id条件。假设我们通过GUC参数获取当前租户：
// 在重写器中遍历所有范围表
foreach(lc, query->rtable) {
RangeTblEntry *rte = (RangeTblEntry *)lfirst(lc);
if (rte->rtekind == RTE_RELATION &&
strcmp(rte->relname, "orders") == 0) {
// 构建tenant_id = xxx的条件
Node *tenant_filter = make_simple_clause("tenant_id",
GetCurrentTenantId());
// 将新条件与原WHERE子句合并
query->jointree->quals = make_and_qual(query->jointree->quals,
tenant_filter);
}
}
四、高级技巧与注意事项
4.1 参数化查询处理
预处理语句的参数需要特殊处理。比如遇到$1这样的参数引用时：
if (IsParam(query->limitOffset)) {
// 需要解析参数值类型
Param *param = (Param *)query->limitOffset;
Oid param_type = list_nth_oid(query->paramTypes, param->paramid - 1);
// 根据参数类型做不同处理
if (param_type == INT8OID) {
// 处理bigint类型参数...
}
}
4.2 执行计划影响评估
不是所有重写都能提升性能。建议在插件中加入成本评估：
// 估算重写前后的成本差异
Cost original_cost = estimate_query_cost(query);
Cost rewritten_cost = estimate_query_cost(rewritten_query);
// 只有显著提升时才应用重写
if (rewritten_cost < original_cost * 0.7) {
return rewritten_query;
}
五、生产环境部署方案
我们建议采用渐进式部署策略：
- 日志模式：先只记录重写建议不实际执行
- 影子模式：并行执行新旧查询对比结果
- 灰度发布：按业务流量百分比逐步启用
可以通过GUC参数控制插件行为：
ALTER SYSTEM SET polar_rewrite.enable = on;
ALTER SYSTEM SET polar_rewrite.log_level = 'debug';
六、性能对比测试
在某电商业务中，我们对订单查询进行了重写优化：
| 查询类型 | 原执行时间 | 重写后时间 |
|---|---|---|
| 深度分页 | 1200ms | 45ms |
| 多租户过滤 | 680ms | 150ms |
| OR条件联合查询 | 2300ms | 420ms |
七、常见问题排查
当插件表现异常时，可以检查以下方面：
- 版本兼容性：PolarDB小版本升级可能修改内部数据结构
- 内存泄漏：使用Valgrind检测palloc分配情况
- 查询缓存：重写可能导致计划缓存失效
八、未来发展方向
我们正在探索以下增强功能：
- 基于机器学习的自适应重写策略
- 与PolarDB的HTAP特性深度结合
- 可视化重写规则配置界面
通过自定义查询重写插件，我们成功将某核心业务的查询平均响应时间降低了65%。这种方案特别适合历史包袱重的系统，既能保持SQL兼容性，又能获得性能提升。不过也要注意，过度使用重写可能导致维护复杂性增加，建议控制在必要场景使用。
评论