1. 引言
在数据库应用和系统开发中，查询性能直接决定了用户体验和系统吞吐量。随着数据量增长，慢查询会拖慢整个业务链路。本文系统梳理查询性能优化的常见方法，从索引、SQL 写法、数据库设计、缓存、架构等多个维度展开，帮助开发者建立一套可落地的优化思路。
2. 索引优化
索引是查询优化最直接、最有效的手段之一。合理使用索引可以大幅减少扫描的数据量，但索引并非越多越好，需要结合查询模式权衡。
2.1 合理创建索引
为高频出现在 WHERE、JOIN、ORDER BY、GROUP BY 子句中的字段建立索引，能显著提升查询效率。例如，针对用户表的登录名查询，可以建立唯一索引。
CREATE INDEX idx_user_login_name ON user_table(login_name);
2.2 联合索引与最左前缀原则
当查询条件涉及多个字段时，联合索引往往比多个单列索引更高效。联合索引遵循最左前缀原则，即查询条件必须从联合索引的最左列开始匹配，否则索引可能失效。
— 联合索引 (city, age, name)
CREATE INDEX idx_user_city_age_name ON user_table(city, age, name);
— 走索引
SELECT * FROM user_table WHERE city = '北京' AND age > 20;
— 不走索引（跳过了最左列 city）
SELECT * FROM user_table WHERE age > 20;
2.3 覆盖索引
如果查询所需的列都包含在索引中，数据库可以直接从索引返回结果，无需回表，这种索引称为覆盖索引。覆盖索引能显著减少磁盘 I/O。
— 索引包含 id 和 name，查询只取这两列，可走覆盖索引
CREATE INDEX idx_user_id_name ON user_table(id, name);
SELECT id, name FROM user_table WHERE name = '张三';
2.4 避免索引失效
常见的索引失效场景包括：对索引列使用函数或运算、隐式类型转换、LIKE 以通配符开头、使用 OR 连接非索引列等。开发时应尽量避免这些写法。
— 索引失效：对索引列使用函数
SELECT * FROM user_table WHERE YEAR(create_time) = 2024;
— 索引失效：隐式类型转换（phone 为 varchar，传入数字）
SELECT * FROM user_table WHERE phone = 13800138000;
— 索引失效：LIKE 以通配符开头
SELECT * FROM user_table WHERE name LIKE '%张%';
3. SQL 语句优化
即使索引合理，低效的 SQL 写法仍会导致性能问题。优化 SQL 本身是成本最低、见效最快的手段。
3.1 只查询需要的字段
避免使用 SELECT *，只取出业务真正需要的列，减少网络传输和内存占用。
— 不推荐
SELECT * FROM order_table WHERE status = 1;
— 推荐
SELECT id, order_no, amount FROM order_table WHERE status = 1;
3.2 避免在 WHERE 子句中对字段做运算
对字段做运算或函数处理会导致索引失效，应尽量把运算移到等号右侧。
— 不推荐
SELECT * FROM order_table WHERE amount + 100 > 500;
— 推荐
SELECT * FROM order_table WHERE amount > 400;
3.3 合理使用分页
深分页（如 LIMIT 100000, 20）会导致数据库扫描大量无关数据。可以通过延迟关联或基于游标的分页方式优化。
— 深分页性能差
SELECT * FROM order_table ORDER BY id LIMIT 100000, 20;
— 延迟关联优化：先取主键，再回表取数据
SELECT o.* FROM order_table o
INNER JOIN (SELECT id FROM order_table ORDER BY id LIMIT 100000, 20) t
ON o.id = t.id;
3.4 用 EXISTS 替代 IN（子查询较大时）
当子查询结果集较大而外层表较小时，EXISTS 通常比 IN 更高效，因为 EXISTS 只要找到一条匹配即可提前返回。
— 子查询结果集较大时，EXISTS 更优
SELECT * FROM user_table u
WHERE EXISTS (SELECT 1 FROM order_table o WHERE o.user_id = u.id);
4. 数据库设计与表结构优化
表结构设计是否合理，直接影响查询性能的上限。
4.1 字段类型选择
在满足业务需求的前提下，尽量选择更小的数据类型。例如能用 INT 就不用 BIGINT，能用 VARCHAR(50) 就不用 TEXT。更小的字段意味着更少的存储和更快的扫描。
4.2 反范式设计
在查询频繁、更新较少的场景下，可以适当冗余字段，减少 JOIN 次数。例如在订单表中冗余用户姓名，避免每次查询都关联用户表。
4.3 分表分库
当单表数据量过大（如超过千万级）时，可以通过水平分表或分库来分散压力。常见的分片键包括用户 ID、订单 ID 等，需结合业务查询模式选择。
4.4 冷热数据分离
将访问频繁的热数据和很少访问的冷数据分开存储，例如把历史订单归档到独立表或独立库，减少主表的体积，提升查询速度。
5. 缓存优化
缓存是降低数据库压力的重要手段，适合读多写少、实时性要求不高的场景。
5.1 应用层缓存
使用 Redis、Memcached 等缓存热点数据，例如用户信息、配置项、热门文章列表等。查询时先查缓存，未命中再查数据库并回填缓存。
// 伪代码：先查缓存，未命中再查数据库
String key = "user:info:" + userId;
Object user = redis.get(key);
if (user == null) {
user = userMapper.selectById(userId);
redis.set(key, user, 3600); // 缓存 1 小时
}
return user;
5.2 缓存穿透、击穿与雪崩
缓存穿透指查询不存在的数据导致请求直达数据库，可通过缓存空值或布隆过滤器解决；缓存击穿指热点 key 过期瞬间大量请求打到数据库，可通过互斥锁或逻辑过期解决；缓存雪崩指大量 key 同时过期，可通过随机过期时间或集群部署缓解。
6. 架构层面的优化
当单机数据库无法满足性能要求时，需要从架构层面做扩展。
6.1 读写分离
通过主从复制，把写操作指向主库，读操作分散到多个从库，从而提升整体读吞吐量。适用于读多写少的业务。
6.2 引入搜索引擎
对于全文检索、模糊匹配等复杂查询，数据库往往力不从心，可以引入 Elasticsearch 等搜索引擎，把搜索类查询从数据库剥离。
6.3 消息队列削峰
对于高并发写入场景，可以通过消息队列（如 Kafka、RocketMQ）异步处理，避免瞬时流量直接冲击数据库。
7. 慢查询分析与监控
优化不是一次性的，需要持续监控和定位慢查询。
7.1 开启慢查询日志
以 MySQL 为例，可以开启慢查询日志，记录执行时间超过阈值的 SQL，作为优化的切入点。
— 开启慢查询日志并设置阈值（单位：秒）
SET GLOBAL slow_query_log = ON;
SET GLOBAL long_query_time = 1;
7.2 使用 EXPLAIN 分析执行计划
通过 EXPLAIN 查看 SQL 的执行计划，重点关注 type、key、rows、Extra 等字段，判断是否走索引、扫描行数是否过大。
EXPLAIN SELECT * FROM order_table WHERE user_id = 100;
7.3 建立性能监控体系
通过监控平台（如 Prometheus、Grafana）持续跟踪数据库的 QPS、慢查询数量、连接数等指标，及时发现性能劣化趋势。
8. 总结
查询性能优化是一个系统性工程，通常遵循「先定位、再优化、后验证」的流程。优先从索引和 SQL 写法入手，这是成本最低、见效最快的手段；当数据量和并发上来后，再结合表结构设计、缓存和架构手段做进一步扩展。建议开发者在日常工作中养成使用 EXPLAIN 分析执行计划的习惯，并建立慢查询监控机制，让性能优化有据可依、持续迭代。
