一条SQL从30秒到0.01秒，我只改了一个索引

一条SQL从30秒到0.01秒，我只改了一个索引同样一条SQL，有人跑0.01秒，有人跑30秒，差距就在那几行Explain结果里。很多开发者觉得SQL优化是DBA的事，但真正卡住业务的慢查询，往往死在自己写的那条语句上。今天这篇文章，我会用真实案例把SQL调优的核心逻辑讲透，看完你就知道该从哪下手了。一、慢查询的真相：问题不在数据库，在你的SQL很多团队一遇到性能问题，第一反应就是加机器、升级配置。但根据我这些年的排查经验，80%以上的慢查询问题，根源都在SQL本身。举个最常见的场景：用户登录接口响应超过2秒，排查后发现是下面这条SQL：sqlSELECT * FROM users WHERE email LIKE '%@gmail.com';这条语句看起来没毛病，但仔细一想——LIKE '%xxx'意味着全表扫描，因为通配符在最前面，索引根本用不上。如果users表有500万行数据，那就得逐行比对，不慢才怪。所以，SQL优化的第一步不是调参数，而是先审视你写的SQL本身是否合理。二、Explain：你最该学会看的一张表MySQL提供了一个极其好用的工具——EXPLAIN，它能告诉你数据库到底是怎么执行你那条SQL的。很多人从来没看过这东西，这等于闭着眼睛开车。2、1、先看type列type列反映的是访问类型，性能从好到差依次是：type 含义 性能system 表只有一行记录 最佳const 通过主键或唯一索引定位到一行 极好eq_ref 联表查询时使用了主键或唯一索引 很好ref 使用了非唯一索引 较好range 索引范围扫描 一般index 索引全扫描 较差ALL 全表扫描 最差如果你的Explain结果里type是ALL，基本可以判定这条SQL需要优化了。2、2、再看key和key_lenkey列显示实际用到了哪个索引，key_len显示索引使用的字