电商系统SQL查询优化的常见痛点
电商系统的核心业务场景普遍依赖数据库查询，比如用户浏览商品列表、查看个人订单、后台统计销售数据等。当表数据量增长到百万甚至千万级别时，原本运行正常的SQL语句可能出现耗时从几十毫秒飙升到几秒的情况，严重时会导致接口超时，影响用户购物体验。很多开发者遇到这类问题时，往往不知道从何处入手分析，要么盲目加索引，要么直接扩容数据库，不仅成本高，效果也不稳定。
实战案例：商品列表分页查询优化
问题背景
某电商平台的商品表goods存储了1200万条商品数据，包含商品ID、名称、分类ID、价格、库存、上架状态等字段。运营端需要查询某个分类下的上架商品，按价格升序排序后分页展示，原始SQL语句如下：
SELECT id, goods_name, price, stock FROM goods WHERE category_id = 15 AND is_on_sale = 1 ORDER BY price ASC LIMIT 0, 20;
这条语句在分类ID为15的数据有80万条的情况下，查询耗时达到了2.3秒，完全无法满足运营端的操作需求。
问题定位步骤
首先通过数据库的慢查询日志定位到这条语句，然后使用EXPLAIN命令查看执行计划，执行结果如下：
| id | select_type | table | type | possible_keys | key | rows | Extra |
|---|---|---|---|---|---|---|---|
| 1 | SIMPLE | goods | ALL | idx_category_id | NULL | 800000 | Using where; Using filesort |
从执行计划可以看出，查询类型是ALL全表扫描，虽然存在category_id的索引，但是没有被使用，同时出现了Using filesort排序操作，这两个是查询慢的核心原因。
优化方案实施
首先分析索引失效的原因，原表只有category_id的单列索引，而查询条件同时包含category_id和is_on_sale，排序字段是price，单列索引无法同时覆盖条件和排序需求。因此设计联合索引idx_category_sale_price，包含三个字段：category_id、is_on_sale、price，顺序和查询条件、排序字段的顺序匹配。
创建索引的SQL语句如下：
CREATE INDEX idx_category_sale_price ON goods(category_id, is_on_sale, price);
索引创建完成后，再次执行EXPLAIN查看执行计划，结果如下：
| id | select_type | table | type | possible_keys | key | rows | Extra |
|---|---|---|---|---|---|---|---|
| 1 | SIMPLE | goods | range | idx_category_sale_price | idx_category_sale_price | 1200 | Using where; Using index |
此时查询类型变为range范围扫描，扫描行数从80万降到1200行，同时排序使用了索引，不再需要额外排序操作。优化后的查询耗时降到了28毫秒，性能提升了80倍以上。
另一个案例：用户订单统计查询优化
问题场景
用户端需要查看自己的历史订单总金额、订单数量，原始SQL语句如下：
SELECT COUNT(*) AS order_count, SUM(order_amount) AS total_amount FROM orders WHERE user_id = 12345 AND order_status IN (1,2,3);
orders表有2000万条数据，单用户的订单量平均在50条左右，这条语句的耗时在1.2秒左右，用户点击订单页面时会有明显卡顿。
优化过程
查看执行计划发现，orders表只有user_id的单列索引，查询条件包含user_id和order_status，同样存在索引无法完全覆盖的问题。创建联合索引idx_user_status_amount，包含user_id、order_status、order_amount三个字段，这样索引可以覆盖所有查询条件和统计字段，不需要回表查询数据。
CREATE INDEX idx_user_status_amount ON orders(user_id, order_status, order_amount);
优化后查询耗时降到了15毫秒，同时因为使用了索引覆盖，减少了磁盘IO操作，对数据库的整体负载也有明显降低。
电商系统SQL优化通用技巧
- 优先通过慢查询日志定位需要优化的SQL，不要盲目优化所有语句
- 设计联合索引时，把区分度高的字段放在前面，同时匹配查询条件和排序、分组字段
- 尽量避免在查询条件中对字段使用函数或者运算，比如
WHERE DATE(create_time) = '2024-01-01'会导致索引失效 - 分页查询时，如果偏移量很大，可以用延迟关联的方式优化，比如先查主键再关联查询需要的字段
- 定期分析表的统计信息，避免执行计划因为统计信息过期出现错误选择
注意：索引不是越多越好，过多的索引会影响插入、更新、删除操作的性能，需要根据实际查询频率合理设计。