SQLAdvisor终极指南：3步跑通智能索引优化建议-尧图网络科技

SQLAdvisor终极指南：3步跑通智能索引优化建议

【免费下载链接】SQLAdvisor输入SQL，输出索引优化建议项目地址: https://gitcode.com/gh_mirrors/sq/SQLAdvisor

线上业务半夜又卡了，慢查询日志刷出满屏红字，你盯着EXPLAIN里的type=ALL干瞪眼——索引到底该建在哪几列？由美团点评 DBA 团队开源的 SQLAdvisor 索引优化建议工具，专治这种"手猜索引"的窘境：输入一条 SQL，它直接吐出建索引的 ALTER 语句。它是开发者和运维新手的慢查询索引优化建议利器，不需要你成为索引理论专家也能用。

一条慢查询，凭什么让全公司等你？

先看一个每天都在发生的场景：接口超时、日志报警、DBA 群里 @ 你。你打开慢查询日志，找到那条跑 8 秒的 SQL，然后开始最原始的"人工建索引"——先试单列，再试联合，每改一次都要等环境刷表、回放流量、对比耗时。运气好半小时解决，运气不好折腾到半夜。

问题在于：联合索引的列顺序、字段区分度、与已有索引是否冲突，这些变量组合起来的可能性远超大脑能穷举的范围。靠直觉猜，本质是在和数据库优化器赌博。

故事：电商新运维的"索引焦虑"之夜 🕘

小鹏是某电商团队的运维，负责的订单表已经攒了 3000 万行。新功能上线当晚，商家后台的"月度账单"查询接口超时率飙到 40%，SQL 很简单：select * from orders where user_id=? and create_time>?，可单列索引换了好几轮就是不见效。

他后来拿到一个命令行工具，30 秒内给出建议idx_user_id_create_time(user_id, create_time)，接口 P99 从 8 秒掉到 0.2 秒。这个工具就是 SQLAdvisor。它不优化你的 SQL 写法，只回答一个问题：这棵索引树，该按什么顺序种哪几列。

SQLAdvisor快速上手：三分钟跑通第一条建索引建议 ⚡

别被"编译安装"四个字吓到，整个流程其实只有三步：拉源码 → 编译 sqlparser → 编译 sqladvisor。

git clone https://gitcode.com/gh_mirrors/sq/SQLAdvisor cd SQLAdvisor cmake -DBUILD_CONFIG=mysql_release -DCMAKE_BUILD_TYPE=debug \ -DCMAKE_INSTALL_PREFIX=/usr/local/sqlparser ./ make && make install cd sqladvisor/ cmake -DCMAKE_BUILD_TYPE=debug ./ make

编译完成后，sqladvisor/目录下会多出一个可执行文件。注意：它需要连上真实的 MySQL 实例读取表结构和索引信息，所以先备好一个有权限的账号。然后直接传参调用：

./sqladvisor -h 127.0.0.1 -P 3306 -u root -p '你的密码' -d shop \ -q "select * from orders where user_id=10086 and create_time>'2024-06-01' order by create_time desc" -v 1

日志末尾会出现关键的一行：

第5步：开始输出表orders索引优化建议: Create_Index_SQL：alter table orders add index idx_user_id_create_time(user_id, create_time)

看到Create_Index_SQL，说明它已经替你把索引方案写好了。复制这条 ALTER 语句到测试库验证，再决定是否上生产——三分钟的正反馈就这么到手了。

这里有个小技巧：SQL 一长、含特殊字符，命令行转义就容易翻车，建议改用配置文件方式：

cat > sql.cnf <<'EOF' [sqladvisor] username=root password=你的密码 host=127.0.0.1 port=3306 dbname=shop sqls=select * from orders where user_id=10086; EOF ./sqladvisor -f sql.cnf -v 1

原理的日常意义：它像老中医，先问诊再开方 🔍

你不必记住它内部的函数名，只要理解它"问诊"的思路，就能判断它的建议值不值得听。整条决策链路可以概括为：拆 SQL 的骨架 → 称每个字段的"本事" → 按最左前缀开方。

图：从 SQL 入口到输出建索引语句的完整链路，where、join、group by、order by 都会被依次"问诊"

第一件事是拆解 SQL。它剥出 where 条件里的等值判断、多表 join 关系，以及 group by / order by 字段。有个细节值得记住：它只信任 AND 连接的条件，遇到 OR、子查询、函数包裹的字段会直接跳过而不是报错，这点避坑部分会细说。

图：解析 join 条件时，工具会区分普通条件与二元运算，只为真正连接两张表的字段建立关联

第二件事是算区分度（Cardinality）。通俗讲，区分度就是"这个字段能区分多少行数据的本事"：主键几乎一行一个值，区分度极高；status只有两三种取值，区分度极低。SQLAdvisor 会连库读取行数与现有索引信息，给每个条件字段打分，然后按区分度从高到低排队。

图：区分度计算会参考表行数与现有最优索引，决定字段在联合索引中的先后位置

第三件事是开方。数据库走索引讲究最左前缀：联合索引(a, b, c)只有在查询先命中a时才能顺利用上b、c。所以等值条件排最前、区分度高的优先，再检查表上有没有已存在的等价索引，避免重复建设——最终就输出你看到的Create_Index_SQL。

新手最容易踩的 3 个坑（附补救办法）🚧

坑一：以为它"读懂"了整条 SQL。子查询、OR 条件、函数加工过的字段，SQLAdvisor 是直接忽略的。拿一条复杂嵌套 SQL 去测，得到的建议可能"缺斤少两"，而且它不会提醒你。补救办法：把 SQL 拆成多条简单语句分别分析，或先手动剥离子查询，再看 where 与 join 各自独立的建议。

坑二：命令行传参被引号坑。SQL 里带双引号或反引号时，必须用\转义，稍不留神就解析失败、建议跑偏。补救办法：别跟 shell 斗智斗勇，直接用-f走配置文件，SQL 写在文件里最省心。

坑三：编译报错找不到libperconaserverclient_r。工具的 SQL 解析依赖 Percona 客户端库，缺失时make会在链接阶段失败。补救办法：安装 Percona-Server-shared-56 包；若库文件带版本号后缀，再建软链接（如ln -s libperconaserverclient_r.so.18 libperconaserverclient_r.so）。

最后补一句：SQLAdvisor 给的是"建议"而不是"圣旨"。它基于统计信息做判断，可能与真实执行计划有出入，上生产前务必用EXPLAIN复核一遍。