SQLAdvisor 上手实战一条 SQL 换来一份靠谱的索引优化建议【免费下载链接】SQLAdvisor输入SQL输出索引优化建议项目地址: https://gitcode.com/gh_mirrors/sq/SQLAdvisor如果你每天都要和慢查询打交道一定明白索引优化建议四个字的分量。SQLAdvisor 正是这样一款开源工具把一条 SQL 丢进去它就能自动输出索引优化建议。它由美团点评 DBA 团队长期打磨内部大规模使用多年后才开源。本文不堆原理术语只讲三件事它是什么、怎么跑通、背后那套取舍逻辑到底怎么想。慢查询的烦恼为什么索引优化总是依赖老法师数据库变慢十有八九与 SQL 没走对索引有关。但现实往往很尴尬建索引看起来简单建对的索引却要同时掂量 where 条件、join 关系、排序分组explain 输出的一大堆字段没有经验的人根本读不懂每一条慢 SQL 都要人工逐条分析DBA 的时间就这样被零碎消耗掉。索引优化本身见效极快真正的成本全部藏在分析这个环节。如果能把这套经验固化成标准化流程让机器替人完成大部分判断DBA 就能把精力留给真正棘手的故障和架构问题。SQLAdvisor 正是奔着这个目标而来的。SQLAdvisor 是什么一个会读 SQL 的索引参谋用一句话概括输入 SQL输出索引优化建议。这份参谋能力来自三层积累基于 MySQL 原生词法解析对 SQL 语法的理解足够准确综合判断 where 条件、字段区分度Cardinality、聚合条件与多表 Join 关系由美团点评 DBA 团队在长期线上运维中反复验证成熟稳定后才对外开源。换个更直观的说法它就像一位经验丰富的老 DBA 坐在你旁边。你递上一条 SQL它先翻看表的统计信息掂量每个字段挑数据的能力再结合索引排列的固有规则最后告诉你该补一个什么样的索引。上图是 SQLAdvisor 从拿到 SQL 到输出索引建议的完整链路先拆分 where 与 join再计算字段区分度接着处理 group by / order by最后过滤重复索引并输出结论。零基础上手三步跑通你的第一条建议 动手之前先备齐这些依赖编译环境并不挑剔常见 Linux 发行版都能满足GCC 4.8 及以上版本CMake 2.8 及以上版本glib2 开发库Percona Server 客户端共享库编译 sqladvisor 本体时依赖 libperconaserverclient_r。获取源码git clone https://gitcode.com/gh_mirrors/sq/SQLAdvisor编译要分两段走整个编译过程可以拆成两个相对独立的阶段先产出 SQL 解析库再编译工具本体。第一步在项目根目录编译 sqlparser 解析库cmake -DBUILD_CONFIGmysql_release -DCMAKE_BUILD_TYPEdebug -DCMAKE_INSTALL_PREFIX/usr/local/sqlparser ./ make make install第二步进入 sqladvisor 子目录编译可执行文件cd sqladvisor cmake -DCMAKE_BUILD_TYPEdebug ./ make编译完成后当前目录下会生成 sqladvisor 可执行文件。这里有两个小提示安装前缀路径尽量保持默认值后续编译会依赖这个目录如果系统报找不到 libperconaserverclient_r多半需要手动建一个软链接指向实际的库文件。两种调用姿势按需选择sqladvisor 支持命令行与配置文件两种传参方式参数含义如下参数作用-h / -P数据库主机与端口-u / -p用户名与密码-d数据库名-q要分析的 SQL-v是否输出日志1 输出0 静默-f指定配置文件命令行方式适合临时验证单条 SQL./sqladvisor -h 127.0.0.1 -P 3306 -u root -p your_password -d test -q SELECT * FROM orders WHERE user_id100 -v 1配置文件方式更适合批量分析。把连接信息写进配置段多条 SQL 用分号隔开[sqladvisor] usernameroot passwordyour_password host127.0.0.1 port3306 dbnametest sqlsSELECT * FROM orders WHERE user_id100;UPDATE orders SET status1 WHERE id5随后通过-f指定该文件即可。日常使用建议优先走配置文件既能避开长 SQL 在命令行里的转义麻烦也方便把一批待检查的 SQL 沉淀下来反复使用。它到底是怎么想的核心逻辑四个环节环节一拆解 where 条件与 join 关系工具先把 SQL 的骨架拆开。where 部分只认 AND 连接的条件OR 因为难以处理会被直接忽略如果条件里藏着 join 关系join on 有时会写在 where 中也要单独识别出来。对于 join它把表关系整理成二叉树存储再按后序遍历逐层还原关联结构同时把 right join 统一转换为 left join简化后续处理。环节二给每个字段算区分度区分度Cardinality衡量的是一个字段挑数据的本事同样的过滤条件下能筛掉越多行的字段区分度越高越值得放在索引前面。计算过程大致如下通过 show table status 拿到表的总行数从表中挑出已存在的最优索引作为采样依据优先级为主键 唯一键 普通索引在表中采样一部分行统计命中过滤条件的行数比例区分度过低例如小于 30的条件直接放弃不参与建索引。环节三按最左前缀原则拼装索引算完区分度接下来就是把条件字段排队。由于索引对字段顺序极其敏感排在索引最前面的字段决定了索引能否被命中工具于是把所有候选字段按区分度从高到低倒序排列再依照等值 排序/分组 非等值的优先级组合出候选索引。那些已经存在于现有索引中的字段组合会被跳过避免给出毫无意义的重复建议。环节四过滤重复输出最终建议最后一步是查漏对照表上现有的索引把尚未建立且确实值得建立的组合整理成建议输出。这一步保证了最终交付的不是一份理想化的索引清单而是真正可落地的增量建议。容易被忽略的进阶规则group by / order by 不是想加就能加聚合与排序字段能否并入索引有一组严格的准入条件相关字段必须全部来自同一张表且这张表必须是确定下来的驱动表group by 与 order by 只能二选一group by 优先级更高order by 的多个字段排序方向必须完全一致否则整组丢弃若 order by 末尾正好是主键主键会被忽略主键出现在其他位置则整组无效。通过校验的 group / order 字段会按规则依次并入备选索引链表最终与 where 条件字段一起构成完整的索引建议。驱动表是怎么选出来的多表查询中SQLAdvisor 会先圈定候选驱动表再逐个估算每张表在首个索引字段过滤下的结果集大小借助 explain 计算行数最终把结果集最小的表定为驱动表。驱动表确定之后其余被驱动表的索引再根据 join 条件补齐。索引字段的出场顺序优先级所有候选索引列的排序遵循一条总原则等值条件 排序/分组字段 非等值条件。这与 MySQL 索引匹配的规律完全吻合——等值条件能最大程度地利用索引定位能力理应永远排在前面。实战避坑指南 ⚠️认清能力边界SQLAdvisor 支持 insert、update、delete、select、insert select、select join 以及 update t1 t2 等常见写法。但下面这些场景会被主动忽略子查询OR 连接的条件使用函数包裹的条件字段非前缀匹配的 like 条件。换句话说它不是万能优化器而是擅长处理规规矩矩的单表过滤与多表关联场景。命令行传参的两个坑直接在命令行传 SQL 时有两处易踩的雷SQL 里的双引号需要用反斜杠转义反引号最好干脆去掉否则解析容易出错。这也是前面反复建议改用配置文件传参的原因。什么时候用它最划算结合团队的实际使用经验下面几类场景收益最大新系统上线前的 SQL 体检提前发现索引缺失隐患慢查询日志中的高频 SQL 批量分析数据库性能瓶颈排查时的快速定位日常巡检中的定期复查把索引优化变成例行工作。建议与 explain 搭配验证SQLAdvisor 给出的是基于规则与统计信息的建议最终效果仍建议用 explain 手动确认执行计划是否如预期。把它当成高水平参谋而非最终裁决者才是正确的打开方式。写在最后 索引优化本是一项高度依赖经验的工作SQLAdvisor 的真正价值在于把这份经验沉淀成可复用的标准化工具让 DBA 从重复劳动中解脱出来。从安装到跑通第一条建议通常用不了多少时间更值钱的是理解它背后那套取舍逻辑——搞懂了它你自己也会成为更懂索引的人。【免费下载链接】SQLAdvisor输入SQL输出索引优化建议项目地址: https://gitcode.com/gh_mirrors/sq/SQLAdvisor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考