吐槽某上市公司接口请求太慢，结果被狠狠教育了。。。

鸭哥2024年10月25日约 5 分钟

今天我们来聊聊一个程序员的常见“翻车现场”，某上市公司的项目，一个接口请求能跑出6秒到12秒，甚至最慢的一次达到了一分钟。

这要是放在用户体验敏感的环境里，估计分分钟就得“凉凉”。不过，话说回来，这家公司面对的是体制内客户，项目还能正常运作这么多年，估计也是“幸存者偏差”吧。

首先，一看到这段SQL代码，我的第一反应就是：“这SQL咋回事？没有索引、SELECT *、还到处用date_format？”作为一个Java开发工程师，我必须跟大家好好聊聊这些问题。

很多人看到SELECT *就本能地觉得是罪魁祸首，但事情没那么简单。SELECT *本身并不是导致查询速度变慢的主要原因。

其实在大多数情况下，尤其当数据量不大的时候，SELECT *不会对查询速度产生明显的负面影响。但为什么老程序员们对它如此嗤之以鼻呢？主要原因在于，SELECT *会导致你取出大量不必要的数据。

如果你的表字段不多，性能问题不会很明显。但当字段一多，甚至表里的字段多达几十个甚至上百个时，这就会导致大量不必要的数据传输，浪费数据库的IO资源。举个例子：

SELECT * FROM user WHERE id = 123;

如果表里的字段不多，这种查询方式影响不大。但如果表中的字段多了，这样的查询将返回一堆你不需要的数据，这时，SELECT *显然就显得不太合适了。通常我们会建议明确地写出你所需要的字段，比如：

SELECT id, name, email FROM user WHERE id = 123;

这样，数据库只会返回你真正需要的数据，减少了IO负担，查询速度自然就提高了。然而，SELECT *带来的问题还算小，真正的问题出在SQL中的date_format函数。

这段代码中更大的问题是使用了date_format，这玩意儿可是个“索引杀手”。我们都知道，索引是加速查询的关键，而date_format的使用会直接导致索引失效。比如：

SELECT o.* 
FROM order o 
WHERE DATE_FORMAT(o.valid_time, '%Y-%m-%d') >= CURRENT_DATE;

这段查询代码，表面看起来没有什么大问题，但由于使用了DATE_FORMAT，MySQL无法使用索引进行优化，导致全表扫描。

原理很简单，索引是基于列的原始值建立的，而DATE_FORMAT修改了列的值，这样索引就“废”了。要想让查询更高效，正确的做法是避免对索引列使用函数，改成：

SELECT o.* 
FROM order o 
WHERE o.valid_time >= CURRENT_DATE;

这样一来，索引就能正常工作，查询速度自然快得多。回到帖子中提到的问题，SQL中的全表扫描加上没有索引的表设计，才是查询速度慢的真正原因。

说到索引，这段代码的另一个问题是根本没有为一些重要字段添加索引。举个简单的例子，假设你有这样一个查询：

SELECT o.* 
FROM order o 
WHERE o.store_id = 1;

如果store_id没有索引，数据库就只能进行全表扫描。数据量少的时候还好说，但一旦数据量上去了，全表扫描的代价就会非常大，查询速度会严重受影响。要解决这个问题也很简单，给store_id加上索引：

CREATE INDEX idx_store_id ON order (store_id);

加了索引后，查询就变成了在索引树上查找，效率大幅提高。

代码里还有一个值得注意的问题，那就是多个条件的筛选。比如这段代码中有类似这样的条件：

<if test="userId != null">
    AND o.user_id = #{userId}
</if>
<if test="courseId != null">
    AND o.course_id = #{courseId}
</if>

当查询有多个条件时，单个字段的索引可能已经不够用了。这种情况下，我们可以考虑建立联合索引，比如user_id和course_id是常用的查询条件，我们可以为它们创建联合索引：

CREATE INDEX idx_user_course ON order (user_id, course_id);

这样数据库在执行查询时，能够同时利用多个字段的索引，查询速度会更快。另外，代码中重复的WHERE条件筛选也是个问题。

我们可以考虑通过重构代码，提取公共逻辑，减少SQL的冗余部分。这不仅让代码看起来更简洁，而且也能提高性能。

讲了这么多，其实SQL优化还不止是这些。优化SQL查询的过程是个细致活儿，涉及到数据库设计、索引使用、SQL语句编写、查询分析等方方面面的知识。

哪怕是稍微改进一点点，比如删除多余的date_format或者添加一两个索引，都可能大大提高查询速度。

最后，SQL优化不能仅仅靠拍脑袋去猜，工具的使用也是至关重要的。MySQL的EXPLAIN命令就是常用的查询分析工具，它可以告诉我们每个查询的执行计划。比如你可以这样分析查询：

EXPLAIN SELECT * FROM order WHERE store_id = 1;

这条命令会返回一系列执行计划，包括查询是否走了索引、是否会进行全表扫描等详细信息。有了这些数据，我们就能更有针对性地进行优化，而不是盲目地“拍脑袋”去猜问题。

综上所述，这个项目接口慢的问题，并不是简单的SELECT *导致的，而是多种因素的综合作用。其实，优化SQL查询不仅仅是为了让代码跑得更快，更是为了避免当数据量变大时，项目突然“崩掉”。

这家公司面对的是体制内客户，或许对性能的要求没有那么严格，但如果是面向大众，分分钟就得被用户吐槽到退市。所以说，SQL优化这件事儿，真的不能忽视。那么大家怎么看呢？欢迎大家评论区留言分享！

对编程、职场感兴趣的同学，大家可以联系我微信：golang404，拉你进入“程序员交流群”。

来自同一个声音