1. SQL优化实战：从索引策略到查询性能飞跃
数据库查询性能优化是每个开发者必须掌握的硬核技能。记得去年我们系统遇到一个典型性能问题：用户行为报表查询平均耗时4.8秒，经过索引优化后降至0.5秒。这种从秒级到毫秒级的性能跃升，正是SQL优化的魅力所在。本文将分享我在千万级数据场景下的实战经验，涵盖索引策略、执行计划解析和查询重写技巧，无论你是刚接触SQL的新手还是想深入优化的老手，都能获得可直接落地的解决方案。
2. 索引策略体系构建
2.1 单列索引的精准定位
在用户行为分析场景中，时间范围查询是最常见的操作。我们以user_behavior表为例，该表有1200万条记录，包含user_id、action_type、create_time等字段。在没有索引的情况下，执行以下查询：
sql复制SELECT * FROM user_behavior
WHERE create_time BETWEEN '2023-01-01' AND '2023-12-31';
耗时达到4.8秒，EXPLAIN显示type=ALL（全表扫描）。这时创建单列索引：
sql复制CREATE INDEX idx_create_time ON user_behavior(create_time);
优化后查询耗时降至0.5秒，EXPLAIN显示type=range且key=idx_create_time。这里需要注意：
- 时间字段建议用DATETIME而非TIMESTAMP，避免时区转换开销
- 索引列不要用在函数中，如
YEAR(create_time)=2023会使索引失效 - 对于更新频繁的表，索引过多会影响写入性能
实测案例：某电商平台订单表添加create_time索引后，促销期间查询QPS从50提升到1200
2.2 复合索引的最左前缀法则
订单表orders经常需要按时间和品类联合查询：
sql复制SELECT * FROM orders
WHERE create_time BETWEEN '2023-01-01' AND '2023-12-31'
AND category='电子产品';
创建复合索引时，必须考虑最左前缀原则：
sql复制CREATE INDEX idx_time_cat ON orders(create_time, category);
这样设计是因为：
- 先按create_time排序，再在相同时间范围内按category排序
- 单独查category时该索引无效（违反最左前缀）
- 字段顺序选择：高区分度在前，常用条件在前
通过执行计划可以看到Extra列出现"Using index condition"，说明索引条件下推(ICP)生效，性能提升300%。
2.3 覆盖索引的极致优化
统计类查询往往只需要部分字段：
sql复制SELECT user_id, COUNT(*)
FROM orders
GROUP BY user_id;
这时可以创建覆盖索引：
sql复制CREATE INDEX idx_order_covering ON orders(user_id, status);
关键优势：
- 索引包含所有查询字段，避免回表操作
- 对于InnoDB，主键会自动附加到二级索引后
- 适合统计查询但会增大索引体积
实测在800万订单数据中，使用覆盖索引后查询速度从2.1秒提升到0.3秒。
3. 执行计划深度解析
3.1 EXPLAIN关键指标解读
拿到执行计划后要重点看这些指标：
| 指标 | 优化目标 | 典型问题 |
|---|---|---|
| type | 至少达到range | ALL(全表扫描)需优化 |
| key | 使用预期索引 | NULL表示未用索引 |
| rows | 扫描行数尽量少 | 值过大需优化 |
| Extra | 避免Using filesort | Using temporary需警惕 |
3.2 索引失效的六大陷阱
- 隐式类型转换：字段定义为varchar但用数字查询
- 前导通配符：
LIKE '%xxx'无法使用索引 - 函数操作：
WHERE YEAR(create_time)=2023 - OR条件不当：OR两侧字段需都有索引
- !=操作符：多数情况不走索引
- 索引选择性差：如性别字段建索引效果差
4. 查询重写实战技巧
4.1 分页查询优化
典型的分页性能问题：
sql复制SELECT * FROM orders
ORDER BY create_time DESC
LIMIT 100000, 10; -- 性能差
优化方案：
sql复制SELECT * FROM orders
WHERE create_time < '2023-06-01' -- 上次分页的边界值
ORDER BY create_time DESC
LIMIT 10;
配合复合索引(create_time DESC, id)效果更佳。
4.2 JOIN优化三原则
- 小表驱动大表：确保JOIN顺序正确
- 关联字段索引：ON条件的字段必须索引
- **避免SELECT ***：只取必要字段
4.3 子查询转JOIN
低效写法：
sql复制SELECT * FROM users
WHERE id IN (SELECT user_id FROM orders WHERE amount > 1000);
优化为：
sql复制SELECT DISTINCT u.*
FROM users u JOIN orders o ON u.id = o.user_id
WHERE o.amount > 1000;
5. 高级优化策略
5.1 索引跳跃扫描
MySQL 8.0的新特性，对于复合索引(gender, age)，即使查询条件没有gender：
sql复制SELECT * FROM people WHERE age > 30;
优化器会自动尝试不同gender值来利用索引，但性能不如直接使用age索引。
5.2 不可见索引
测试索引效果时可用：
sql复制CREATE INDEX idx_test ON table(col) INVISIBLE;
ALTER TABLE table ALTER INDEX idx_test VISIBLE;
避免直接创建/删除索引影响生产环境。
5.3 直方图统计
MySQL 8.0的直方图功能优化非索引列查询：
sql复制ANALYZE TABLE orders UPDATE HISTOGRAM ON category;
这对无法建索引的字段特别有用。
6. 性能监控与调优
6.1 慢查询日志配置
sql复制SET GLOBAL slow_query_log = ON;
SET GLOBAL long_query_time = 1; -- 超过1秒的记录
SET GLOBAL log_queries_not_using_indexes = ON;
定期分析慢日志找出优化点。
6.2 性能模式(Performance Schema)
监控索引使用情况：
sql复制SELECT * FROM performance_schema.table_io_waits_summary_by_index_usage
WHERE OBJECT_SCHEMA='your_db';
使用率低的索引可以考虑删除。
7. 真实案例复盘
某电商平台大促期间出现数据库CPU飙升，经分析发现：
- 核心查询缺少
(user_id, status)复合索引 - 存在大量
SELECT *查询 - 分页查询没有使用边界值优化
优化措施：
- 增加3个关键复合索引
- 重写15个核心查询
- 引入缓存层
最终效果：数据库QPS从800提升到3500，CPU负载从90%降至40%。这个案例告诉我们，索引优化往往能以最小成本获得最大收益。