[专访] “60% 的 DB 故障源于 SQL……调优优先,扩容在后”
Openmade Consulting 解决方案事业本部 Jang Cheol-woong 常务专访

[IT Daily] “超过 60% 的 DB 性能 故障始于 SQL。在增设硬件之前,必须先优化 SQL。这是 CIO 现在能采取的最现实的成本削减战略。我们称之为‘先调优,后扩容 (Tune First, Expand Later)’。”
Openmade Consulting 的 Jang Cheol-woong 常务最近在接受本报(IT Daily/Computer World)采访时,针对 AI 时代的基础设施成本问题提出了上述解决方案。Jang 常务凭借在 IT 行业从硬件到系统集成 (SI)、大数据、DB 的多年现场经验,目前在 Openmade Consulting 负责基于 AI 的 SQL 自动优化解决方案 “Query Medic” 的销售工作。
“基础设施通胀时代……没有 SQL 优化,财务控制无从谈起”
今年企业 IT 环境正处于复杂局势。根据 DB 性能优化专业公司 Openmade Consulting 最近发布的报告,随着全球 AI 服务器市场规模增长至约 2,200 亿美元,GPU 和内存半导体价格飙升,预计 DRAM 价格将同比上涨 50% 以上。
因此,即使想扩容服务器,货源也难以保障,即使能买到,成 本也会呈几何级数增长,所谓的“基础设施通货膨胀”阶段正在持续。
为了降低成本而选择迁移至 Cloud 的企业情况也大同小异。Cloud 环境是根据资源使用量进行计费的结构。如果搬迁未经优化的 SQL,多余的 I/O 和 CPU 消耗将直接导致运营成本暴涨。据行业调查,10-30% 的 Cloud 支出因低效查询而浪费。
Jang 常务诊断称:“无论基础设施如何增加,如果其上运行的 SQL 效率低下,成本就会无止境地流失。对于 CIO 而言,无论购买服务器还是使用 Cloud,没有 SQL 优化,财务控制都将变得不可能。”
“SQL 调优每天 3-4 件已是极限……产生管理盲区”
问题在于由谁来进行这种 SQL 优化。据 Jang 常务介绍,一线的 DB 管理人员忙于维护系统可用性和应对故障等运维工作,无暇顾及性能改善。虽然有时会聘请外部专家进行调优,但一名资深 DBA 每天能处理的 SQL 调优数量上限仅为 3-4 件。难度大的查询甚至需要一周时间才能处理一条。
Jang 常务表示:“目前对问题查询列表的管理主要依靠负责人或团队,基本处于结合个人经验进行管理的水平。已知的问题尚可管理,但未知的‘伏兵’不断累积,某天突然爆发故障,这才是真正的危险。”
这些问题在开发一线也成为了瓶颈。例如,如果一个 IT 机构有 300 名开发人员,每个人都会编写 SQL,但缺乏能够验证自己编写的查询性能的调优专家。开发人员即使想申请调优也没有人受理,而 DBA 则忙于自己的运维工作,没有时间查看他人的查询。
Jang 常务指出:“开发部门和 DB 运维部门都深切感受到了调优的必要性,但处于无法互相解决问题的境地。这是目前韩国国内 IT 机构面临的最大结构性问题。”
“从探测到调优、验证,全过程 AI 自动化”
为了解决这些问题,Query Medic 应运而生。Openmade Consulting 21 年来以金融领域为中心,向客户派遣 DBA、调优师、建模师,积累了丰富的 DB 性能管理经验,并整合这些技术诀窍开发运营了 “OpenPOP”。OpenPOP 是一个对 SQL 从开发到运行的全过程进行性能检查、验证和控制的解决方案,通过在运行环境中应用全天候 24/7 的故障预防流程来先发制人地防止故障发生。
据 Jang 常务介绍,客户不断提出需求:“能不能不只是提供指南,而是让调优本身也实现自动化?” 虽然 OpenPOP 可以找出问题,但实际修改 SQL 的工作仍然需要人工完成。
因此,在两年前 AI 技术飞速发展之际,公司启动了正式的 Query Medic R&D,将 LLM 的推理能力与 OpenPOP 的探测及验证引擎相结合。其核心在于实现了从自动提取性能下降 SQL 到生成最佳调优结果、再到验证调优结果的全过程自动化。该产品已于去年 10 月正式发布。
其中也融入了源自实战经验的精细调优逻辑。在实际 DB 运行环境中,同一条 SQL 在不同时间、出于不同目的执行时,其最佳调优方法往往不同。
例如,对于白天必须立即响应用户请求的 OLTP 查询,哪怕快 0.1 秒返回结果也是关键;而对于凌晨耗时数小时处理海量数据的 Batch 查询,减少总吞吐量以在规定时间内完成任务比单次响应速度更重要。Query Medic 会自动判别目标 SQL 的类型和执行模式,并应用适合各种情况的优化逻辑。
Jang 常务解释道:“如果将查询输入普通 AI,会得到教科书式的答案,但在实际场景中往往行不通。引擎中包含了多年在金融行业一线的实战经验,例如在特定情况下哪种调优方法效果更好,这种判断标准使得结果的质量截然不同。”
“AI 修复的 SQL 是否可靠是关键”
Jang 常务特别强调了 Query Medic 的核心差异点——“基于 AI 的验证”功能。他解释说,虽然使用通用 AI 工具也能获得 SQL 调优结果,但这些结果能否直接应用于生产环境则是完全不同的问题。
Jang 常务表示:“将 SQL 输入 ChatGPT 或 Gemini 确实能得到看似合理的调优方案。但由于结果缺乏一致性,无法应用于运行环境。事实上,许多企业曾尝试引入自己的 LLM 模型进行 SQL 调优,但大多因为无法信任结果而放弃了实际应用。”
Query Medic 在包含实际运营数据的 DB 环境中直接执行 AI 生成的调优方案,并自动对比验证调优前后的结果值和数据量是否完全一致。
Jang 常务强调:“目前无论在韩国还是全球,都还没有能够实现从调优到验证全流程自动化的解决方案。这项验证功能非常特别。”
“一名 DBA 每月 60 件,Query Medic 每天超过 1,000 件”
据 Jang 常务介绍,一名 DBA 每天能处理 of SQL 调优数量上限约为 3 件。简单计 算一下,按每月工作 20 天计算为 60 件,每年约为 720 件。Query Medic 全天候 24/365 自动运行,每天可调优超过 1,000 条 SQL。此外,它还能对人类尚未察觉的潜在故障 SQL 进行全量检查并先发制人地排除,从而起到预防故障的作用。
Jang 常务解释道:“人类管理的只是有记录或负责人凭经验了解的一部分。由于 Query Medic 进行全量检查,它可以预先抓捕那些一直无人察觉、某天却突然引发故障的‘伏兵’。”
据称一线对 Query Medic 的期待也很高。Jang 常务表示:“当我们介绍 Query Medic 时,开发人员、DB 负责人和 CIO 的反应最为热烈。对于开发人员来说,他们获得了一种能立即验证所编写 SQL 质量的手段;对于 CIO 来说,则获得了一种无需扩容服务器或增加人力即可提高运营效率并控制成本的工具。”
他补充道:“一家金融客户在 5-6 年间尝试引入各种 AI 模型以取得业务成果,但未能获得满意的结果。在进行 Query Medic 演示和 POC 后,该 IT 部门评价说‘Query Medic 是唯一能用 AI 产生实际业绩的解决方案’。”
目前,Query Medic 正在以公共机构和金融领域为中心扩大应用。已有向公共机构系统重建项目供应 Query Medic 的案例,许多金融公司和公共机构正在进行 POC 或考虑引入。
最近,制造业对该产品的关注也在增加。Jang 常务表示:“韩国大型制造企业在运营海外生产线时,经常因为当地开发人员编写的 SQL 质量问题而导致性能故障。生产线停工会导致巨大的成本损失,随着人们意识到其中很大一部分原因在于运行在 DB 上的 SQL,制造业的咨询大幅增加。”
“我将把‘调优优先’的原则植根于一线”
Query Medic 目前支持 Oracle 环境,并正在快速扩大支持的 DB 范围。PostgreSQL 的开发已基本完成,对韩国国产数据库 Tibero 的支持预计在第二季度内实现。MySQL 的开发正在进行中,目标是下半年。从 2027 年起,计划提供 SaaS 版本。
Jang 常务表示:“这得益于我们在 DB 调优专业领域 21 年积累的技术信誉。我想让市场相信,引入了 Query Medic 的系统是安全的。”
他补充道:“DBA 彻夜熬夜逐条剖析查询的时代应该结束了。我将在一线努力,直到‘先调优,后扩容’这一原则成为 CIO 们的常识。”
产品引进及咨询等业务咨询
02-6310-6167 / qm@openmade.co.kr
来源:IT Daily (http://www.itdaily.kr/news/articleView.html?idxno=238877)
#SQL调优 #AI调优 #数据库性能 #QueryMedic #OpenMade咨询 #数据库优化 #自动化解决方案 #DBA #开发人员 #IT运维 #成本降低 #性能提升 #AI自动化 #DB性能管理 #节省基础设施成本 #CIO