告别慢查询熬夜排查：三步用 SQLAdvisor 生成 MySQL 索引优化建议

告别慢查询熬夜排查：三步用 SQLAdvisor 生成 MySQL 索引优化建议

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

深夜两点，你的手机突然被监控告警震醒——某个核心接口响应从 30ms 飙到 3 秒，线上告警群里一片"＋1"。你登录数据库一看，一条 SELECT 查询把整张表扫了个遍，慢查询日志里它排名第一。加个索引就能解决，但字段这么多，到底该给谁加？加在前面还是后面？如果你也经历过这种"人工试索引"的折磨，那么本文介绍的 SQLAdvisor 就是为你准备的答案。它由美团点评 DBA 团队开源，核心功能一句话说清：输入 SQL，自动输出索引优化建议。

为什么是 SQLAdvisor：三个让它"会说话"的硬实力

在它出现之前，大家是怎么加索引的？要么靠 DBA 多年的经验直觉，要么一条条 EXPLAIN 手动验证，要么干脆把字段全塞进索引里碰运气。SQLAdvisor 则把"索引怎么建"变成了一条可复现的流水线，它的底气来自下面三点。

1. 基于 MySQL 原生词法解析，而不是正则碰运气

很多工具解析 SQL 靠正则表达式，遇到复杂写法就翻车。SQLAdvisor 直接复用 MySQL 自身的解析器（sqlparser 模块），把 SQL 拆成一棵标准的语法树，从根上保证"读得懂"你的语句，这是它输出可靠建议的地基。

2. 计算字段区分度，让高价值字段排前面

索引不是字段越多越好，排列顺序更重要。SQLAdvisor 会估算每个字段的区分度（Cardinality），区分度越高的字段越适合放在索引前列。它甚至会对"字段选择度低于 30"的低价值条件直接放弃，避免给你一堆没用的建议。

3. 处理多表 Join 与驱动表选择，逼近真实执行计划

多表关联是索引优化里最头疼的场景。SQLAdvisor 会解析 Join 关系、构建表关系树，并通过 EXPLAIN 估算各表结果集大小，选结果集最小的表作为驱动表，再给被驱动表补齐 Join 条件索引——这一整套逻辑，和 MySQL 优化器的工作方式高度一致。

下面这张图就是 SQLAdvisor 从收到 SQL 到输出索引建议建议的完整处理流程：

零基础上手：SQLAdvisor 安装教程（三分钟版）

别被"编译源码"四个字吓到，整个过程其实只有三步，跟着走就行。

第一步：准备环境

需要 GCC 4.8+、CMake 2.8+、glib2 开发库，以及 MySQL/Percona 客户端库（编译依赖perconaserverclient_r）。CentOS 系一行搞定：

yum install cmake libaio-devel libffi-devel glib2 glib2-devel

再装上Percona-Server-shared-56，因为编译 sqladvisor 时依赖它的客户端库。如果装完后链接报错，多半是缺少软链接，补一条即可：

cd /usr/lib64/ && ln -s libperconaserverclient_r.so.18 libperconaserverclient_r.so

第二步：克隆源码并编译 sqlparser

先拿到项目源码：

git clone https://gitcode.com/gh_mirrors/sq/SQLAdvisor

然后编译 SQL 解析模块。为什么先编它？因为 sqladvisor 本体是依赖这个解析库的，顺序反了会找不到头文件：

cmake -DBUILD_CONFIG=mysql_release -DCMAKE_BUILD_TYPE=debug -DCMAKE_INSTALL_PREFIX=/usr/local/sqlparser ./ make && make install

这里的CMAKE_INSTALL_PREFIX就是解析库的安装目录，建议保持默认值别乱改，后面的编译会依赖它。

第三步：编译 sqladvisor 本体

cd SQLAdvisor/sqladvisor/ cmake -DCMAKE_BUILD_TYPE=debug ./ make

执行完，当前目录下会生成一个sqladvisor可执行文件，这就是我们要的主角。更多安装细节见官方文档 doc/QUICK_START.md。

第一次运行：验证你的第一条索引建议

连接数据库的姿势很简单，参数名与值之间用空格隔开：

./sqladvisor -h 127.0.0.1 -P 3306 -u root -p '密码' -d testdb -q "SELECT * FROM orders WHERE user_id=100 AND create_time>'2023-01-01'" -v 1

其中-h/-P/-u/-p/-d分别对应主机、端口、账号、密码、数据库名，-q是待分析的 SQL，-v 1表示输出日志。如果一切正常，它会直接告诉你：orders表建议添加(user_id, create_time)这样的索引建议。

一个贯穿全篇的小案例：区分度和最左前缀到底怎么算

我们用上面的订单表查询来拆解。表里有几百万行订单，user_id一个用户可能只下单几十次，而create_time每天都有成千上万条记录——直觉上user_id比create_time更容易把数据"筛"到很小，这在 SQLAdvisor 里就叫区分度高。

SQLAdvisor 拿到 SQL 后，会先通过show table status拿到表总行数，再挑一个表上现有的最优索引做采样，估算每个条件字段的区分度，然后按"区分度从高到低"排列字段，同时套用 MySQL 索引的最左前缀原则：等值条件的字段放最前面。于是user_id=100排在create_time>'2023-01-01'前面，最终建议(user_id, create_time)。

这个"算区分度 → 排序 → 组合索引"的过程，可以参考下面这张流程图，理解起来更直观：

顺便说一句，内部对索引列的整体排序优先级是：等值条件 > (group by | order by) > 非等值条件。如果 SQL 里带了排序或分组，它会额外判断这些字段是否来自同一张表、排序方向是否一致，再决定要不要把它们并入索引——多表场景下的 Join 关系解析逻辑见下图：

⚠️ 避坑清单：新手最容易踩的 6 个坑

工具虽好，但如果你不摸清它的脾气，很容易得到"看似有用、实则无效"的结果。以下是最常见的坑：

• OR 条件、子查询、函数条件会被直接忽略。SQLAdvisor 只处理 AND 连接的普通条件，遇到 OR、子查询、WHERE DATE(create_time)=...这类带函数的写法会跳过。这不是 bug，是设计取舍，遇到这类 SQL 只能人工介入。
• like 非前缀匹配会被丢弃。LIKE 'abc%'能用上索引，但LIKE '%abc'会被丢弃，别指望它给出离谱建议。
• 命令行传 SQL 要转义双引号和反引号。比如-q "SELECT * FROM t WHERE name=\"x\""，反引号建议直接去掉。嫌麻烦的话，官方推荐用配置文件方式调用：把参数写进sql.cnf，然后./sqladvisor -f sql.cnf -v 1。
• group by 和 order by 有限制：字段必须来自同一张表且是驱动表，两者只能保留一个，order by 的排序方向必须完全一致，否则整列丢弃。
• 不要用它分析不支持的语句就放弃。它支持 insert、update、delete、select、insert select、select join 等常见 SQL，覆盖日常绝大多数场景。
• 建议不等于事实。工具给出的是"优化建议"，上线前请务必用 EXPLAIN 手动验证一遍执行计划，尤其是大数据量、高并发的核心表。

小结：谁适合用 SQLAdvisor

如果你是新系统上线前的 SQL 性能评估者，是每天翻慢查询日志的业务 DBA，或者是刚接手线上库、对索引还拿不准的开发者，SQLAdvisor 都能帮你把"凭经验猜索引"变成"按数据说话"。它的定位不是取代你，而是帮你把索引优化的脏活累活标准化、工具化——三分钟装好，一条命令出建议，剩下的判断交给你的业务直觉。想深入理解它的解析树分解、区分度算法细节，可以接着读项目自带的 doc/THEORY_PRACTICES.md 和 doc/FAQ.md。

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