在MySQL日常运维中，很多慢查询并不是因为缺少索引或硬件瓶颈，而是SQL语句本身的写法让优化器无法高效利用已有结构。通过对简单语法的改写，往往能在不调整表设计的前提下显著降低响应时间。下面先看一个典型的反例与优化对照。
一、避免在索引列上使用函数
当我们在WHERE条件中对索引字段使用日期函数或字符串函数时，MySQL无法直接使用该列的B树索引，只能逐行计算后再过滤，本质上是全索引扫描甚至全表扫描。这类写法在报表类查询里极其常见，因为开发者图方便直接用函数截取日期。
例如用户表user上有索引idx_create_time(create_time)，原语句用DATE函数过滤：
-- 反例：在索引列上使用函数，导致索引失效 SELECT id, name, create_time FROM user WHERE DATE(create_time) = '2023-08-01';
优化器在执行上述语句时，会对每一行的create_time调用DATE函数，因此type显示为ALL（全表扫描）。改写方式是将函数计算转移到常量侧，用范围查询覆盖目标日期：
-- 正例：用范围查询代替列上的函数调用 SELECT id, name, create_time FROM user WHERE create_time >= '2023-08-01 00:00:00' AND create_time < '2023-08-02 00:00:00';
改写后EXPLAIN的type变为range，key使用idx_create_time，扫描行数从全表降至当天数据量。这种改法不修改表结构，仅调整语法形态，却能让查询耗时从秒级降到毫秒级。需要注意的是，若业务必须按小时或月汇总，应在应用层先算出起止时间再传入SQL。
二、用JOIN或EXISTS替代子查询中的IN
在老版本MySQL中，对大表使用IN子查询容易生成临时表并做去重，尤其当子查询返回上万条数据时，性能下降明显。很多遗留系统喜欢写嵌套的SELECT ... IN (SELECT ...)，看似直观但执行计划并不友好。
假设我们要查出已下单的用户信息，订单表order_info数据量远大于user表，原始写法如下：
-- 反例：大结果集的IN子查询 SELECT id, name FROM user WHERE id IN ( SELECT user_id FROM order_info WHERE status = 1 );
这种语句在部分MySQL版本中会先物化子查询，再拿user表去匹配，若order_info中status=1的记录有几百万，就会创建巨大临时表。更优的写法是改用JOIN，让优化器选择更合适的驱动顺序：
-- 正例：使用JOIN去重，利用索引关联 SELECT DISTINCT u.id, u.name FROM user u JOIN order_info o ON u.id = o.user_id WHERE o.status = 1;
如果业务只需判断存在性，用EXISTS语义更清晰且常能走半连接优化：
-- 另一种正例：EXISTS半连接 SELECT id, name FROM user u WHERE EXISTS ( SELECT 1 FROM order_info o WHERE o.user_id = u.id AND o.status = 1 ); </p> <p>对比可见，JOIN写法在order_info有user_id索引时，能直接做嵌套循环或哈希连接，避免中间结果膨胀。EXISTS则更早截断不匹配的行。实际改写时应结合EXPLAIN观察rows与Extra字段是否出现Using temporary。</p> <h2>三、拒绝SELECT * 并明确限定列</h2> <p>SELECT * 不仅增加网络传输量，还会使覆盖索引失效。当查询只需两三个字段且这些字段能组成联合索引时，限定列名可让MySQL仅读索引页而不回表，这被称为覆盖索引扫描。</p> <p>以订单表为例，有联合索引idx_uid_status(user_id, status)，若只关心用户ID与状态：</p> <pre class=brush:sql;toolbar:false> -- 反例：选取所有列，无法走覆盖索引 SELECT * FROM order_info WHERE user_id = 10086 AND status = 1;
改写为只取所需列后，索引本身已包含全部输出数据，无需访问聚簇索引：
-- 正例：限定列，触发覆盖索引 SELECT user_id, status FROM order_info WHERE user_id = 10086 AND status = 1;
在EXPLAIN里，改写前的Extra可能出现Using where，改写后则显示Using index，表示纯索引读取。对于宽表（数十个字段）而言，这种简单语法调整能减少大量随机IO。同时，明确列名也让结果集结构稳定，避免表结构变更引发的程序映射异常。
四、用UNION ALL代替OR连接索引列
当WHERE条件中用OR连接两个不同索引列时，MySQL往往放弃使用任一索引而走全表扫描。这并不是绝对，但在复杂条件下很常见。将OR拆成两条独立查询再做UNION ALL，通常能分别利用索引。
比如商品表product有idx_category和idx_brand两个索引，原语句：
-- 反例：OR导致索引合并困难或失效 SELECT id, title FROM product WHERE category_id = 5 OR brand_id = 12;
可拆分为两个索引友好的查询并去重合并：
-- 正例：UNION ALL拆分，各自走索引 SELECT id, title FROM product WHERE category_id = 5 UNION ALL SELECT id, title FROM product WHERE brand_id = 12;
若确定结果无重复或重复可接受，UNION ALL比UNION更高效，因为它不做去重排序。从执行计划看，每个子查询的type都是ref，整体性能远好于原OR写法的ALL。当然，若OR两侧是同一索引的不同值，直接用IN即可，不必拆查询。
五、小结与验证方法
上述几种改写都属于语法层面的微调，核心思路是让MySQL优化器能识别并利用已有索引，避免隐式计算、临时表与全表扫描。在动手改之前，务必用EXPLAIN或EXPLAIN FORMAT=JSON查看原语句的访问类型与扫描行数。
建议在测试环境用真实数据量验证：记录改写前后的query_time与rows_examined，如果后者明显下降且type从ALL/INDEX变为ref/range，说明语法改写生效。对于复杂报表，还可以开启慢查询日志，把long_query_time设小，捕捉需要优化的具体语句。坚持从简单语法入手，往往能以最小成本换来稳定的性能提升。