MySQL平滑迁移GaussDB？一次压测暴露的SQL性能“陷阱”及深度优化实录

在国产化替代的浪潮中，将业务从MySQL等传统数据库迁移到GaussDB等信创数据库，是许多企业正在经历或即将面临的重要课题。

今天，我们想和大家分享一个近期在为某大型能源企业进行POC（概念验证）测试时遇到的真实案例。一条在原环境中运行良好的SQL，迁移到GaussDB后，在压力测试下性能却未达预期。

这个过程颇具代表性，希望能为同样走在信创路上的朋友们提供一些参考。

问题浮现

故事的开端，是一次常规的压测。

客户的业务系统从MySQL迁移至GaussDB后，我们使用JMeter进行压力测试。很快发现，系统的整体吞吐量（TPS）不如预期，通过监控定位到了一条高频执行的SQL，成为了性能瓶颈。

原始SQL：

select t.*,IF('HN01'=t.org code,1,0) AS is_handle,IF('HN01'


    
=t.org code,1,0) AS sort,IF( o.org_code = 'HN01','',IF('HN01'='HN01',(SELECT prop_name FROM base_dim WHERE isdelete=0 AND  prop_code = o.province_code),o.org name ) ) AS org_name,w.tel_phone AS wechatPhoneFROM t_mdata_customer tLEFT JOIN base_org o ON o.org_code=t.org_code AND o.isdelete='0'LEFT JOIN web_user w ON w.id=t.wechat_idwhere t.isdelete='0'ORDER BY is_handle DESC,sort DESC,t.create_time DESC,t.customer_name desc LIMIT 20;

这条SQL的业务逻辑并不复杂，主要是一个分页查询，包含了几个LEFT JOIN和IF函数判断。然而，它在GaussDB（单节点8C64G）上的表现，却与TDSQL环境（16C32G）存在明显差距。

性能分析

SQL语句：

1、TDSQL的执行计划：

2、GuassDB的执行计划：

通过两个执行计划对比发现：TDSQL扫描t表数据后直接排序。排序后再进行join。

通过SQL改写实现相同的计划，GaussDB执行如下：

现在耗时主要在1.0S但是直接执行seq scan。

Seqscan和sort为什么慢还需要确认，初步判断是if判断导到的单表查询，增加 if判断，seqscan就慢了很多，耗时达到了1.1s。

将if判断修改为明确值，seqscan值为620ms。

初步结论：优化器生成的计划不优。

表结构

base_org表

web_user表

t_mdata_customer表

问题解决方法

按照MySQL数据库执行计划思路，去掉排序过程，创建索引:

create index on t_mdata_customer(IF('HN01'=t.org code,1,0) desc,create_time desc,customer_name desc);

创建索引后不能走索引，加了hit也不行，创建索引去掉customer_name字段就可以了，经排查发现，此问题为已知bug，后面版本已解决此bug，规避方法如下：

使用rdsadmin用户登录先查询备份后删除记录：

在查看执行计划就走索引了，执行计划如下：

跳过sort，直接limit20条记录后出了结果，执行时间1毫秒。

再次进行压力测试，系统吞吐量恢复正常，性能瓶颈被彻底消除。

这个案例本身技术难度不算顶尖，但它的排查过程，恰恰是数据库国产化迁移中最具价值的实践缩影。我们想借此分享三点思考：

1、迁移≠复制：从一种数据库迁移到另一种，绝不是简单的“数据搬家”。不同数据库的优化器“脾气秉性”各不相同，必须对核心SQL进行充分的性能回归测试，不能想当然地认为原有的“最优 ”依然适用。

2、经验是灯塔：当遇到看似不合逻辑的“灵异现象”时，往往是深入到了产品本身的特性或边界。此时，深厚的产品知识和丰富的踩坑经验，就成了照亮前路的灯塔。

3、与生态同行：任何数据库产品都在不断迭代进化。了解其版本特性、已知问题和演进路线，是保障系统长期稳定、高效运行的关键。这也是我们作为华为GaussDB核心服务伙伴，持续投入技术研究的价值所在。

我们始终相信，踏踏实实解决好每一个看似微小的技术问题，正是保障客户核心业务稳健前行的基石。

如果您在数据库迁移、性能优化或运维方面遇到任何挑战，欢迎随时与我们交流。