摘要：今天小编通过10个真实场景的优化方案，手把手带你从执行计划分析到索引设计，彻底告别慢查询！
明明只是简单的查询，却要等上10秒？
数据量稍微增长，系统就频繁超时？
慢查询是数据库性能的隐形杀手，而90%的问题可通过优化索引和SQL逻辑解决！
今天小编通过10个真实场景的优化方案，手把手带你从执行计划分析到索引设计，彻底告别慢查询！
问题场景
查询用户表中某手机号用户，但执行耗时2秒：
SELECT * FROM users WHERE phone = '13800138000';分析过程
执行EXPLAIN查看执行计划：EXPLAIN SELECT * FROM users WHERE phone = '13800138000';type=ALL（全表扫描），rows=100000（扫描10万行）原因：phone字段无索引，被迫扫描全表。
优化方案
为phone字段添加索引：
ALTER TABLE users ADD INDEX idx_phone(phone);优化效果
问题场景
订单表按字符串类型的订单号查询，但索引未生效：
SELECT * FROM orders WHERE order_no = 10086; -- order_no是VARCHAR类型分析过程
EXPLAIN结果显示type=ALL，索引idx_order_no未命中。
原因：order_no是字符串类型，但查询条件使用数字，触发隐式转换导致索引失效。
优化方案
保持字段与参数类型一致：
SELECT * FROM orders WHERE order_no = '10086';优化效果
索引命中，查询时间从3秒降至0.02秒问题场景
商品表根据category_id和price查询，但查询依然慢：
SELECT * FROM products WHERE price > 100;分析过程
已为(category_id, price)创建复合索引idx_cat_price。
原因：查询未包含category_id，不满足最左前缀原则，索引失效。
优化方案
调整查询条件或索引设计：
-- 方案1：添加category_id条件（如允许业务调整） SELECT * FROM products WHERE category_id=1 AND price > 100; -- 方案2：单独为price创建索引 ALTER TABLE products ADD INDEX idx_price(price);问题场景
分页查询第100000页数据，耗时8秒：
SELECT * FROM logs ORDER BY id LIMIT 1000000, 10;分析过程
EXPLAIN显示type=ALL，需扫描前1000010行再丢弃。
优化方案
改用游标分页（基于ID连续递增）：
SELECT * FROM logs WHERE id > 1000000 ORDER BY id LIMIT 10;优化效果
扫描行数从100万降至10行，耗时从8秒降至0.005秒问题场景
查询未支付订单的用户信息，子查询耗时6秒：
SELECT * FROM users WHERE id IN (SELECT user_id FROM orders WHERE status = 'unpaid');分析过程
子查询需全表扫描orders，生成临时表后再关联。
优化方案
改写为JOIN查询：
SELECT u.* FROM users u JOIN orders o ON u.id = o.user_id WHERE o.status = 'unpaid';优化效果
避免临时表，查询时间从6秒降至0.3秒问题场景
查询用户姓名和邮箱，但查询缓慢：
SELECT name, email FROM users WHERE age > 30;分析过程
存在索引idx_age(age)，但需回表查询name和email。
优化方案
创建覆盖索引：
ALTER TABLE users ADD INDEX idx_age_cover(age, name, email);优化效果
问题场景
按注册时间倒序查询用户，耗时4秒：
SELECT * FROM users ORDER BY register_time DESC LIMIT 100;分析过程
EXPLAIN显示Using filesort，内存或磁盘排序成本高。
优化方案
为register_time创建索引：
ALTER TABLE users ADD INDEX idx_register_time(register_time);优化效果
排序利用索引，耗时从4秒降至0.1秒问题场景
批量更新10万条用户状态，导致锁等待超时：
BEGIN; UPDATE users SET status = 'active' WHERE create_time分析过程
单事务更新数据量过大，长期持有行锁。
优化方案
分批次提交事务：
SET autocommit=0; WHILE (需要更新的数据) DO UPDATE users SET status = 'active' WHERE create_time优化效果
锁竞争减少，更新耗时从30秒降至5秒问题场景
查询2023年注册的用户，索引未生效：
SELECT * FROM users WHERE YEAR(register_time) = 2023;分析过程
对索引字段register_time使用函数，导致索引失效。
优化方案
改用范围查询：
SELECT * FROM users WHERE register_time >= '2023-01-01' AND register_time优化效果
索引命中，查询时间从3秒降至0.1秒问题场景
统计订单金额时优化器选择错误索引：
SELECT SUM(amount) FROM orders WHERE user_id = 100;分析过程
存在idx_user_id和idx_amount索引，优化器误选idx_amount。优化方案
强制指定索引：
SELECT SUM(amount) FROM orders FORCE INDEX(idx_user_id) WHERE user_id = 100;优化效果
慢查询优化没有标准答案，需结合执行计划分析、索引设计与业务逻辑调整。
请大家记住三个核心原则：
能用索引的不用全表能批量的不单条能拆事务的不长锁以上是MySQL查询优化的10个技巧，大家如果有更好的MySQL查询优化方案欢迎评论区沟通交流！
来源：免费高清壁纸大全
