在数据驱动的业务场景中，MySQL作为主流开源关系型数据库，其性能直接决定系统响应速度、吞吐量和运维成本。尤其是高并发、大数据量的业务场景（如DeepSeek这类AI平台），慢查询和不合理的索引设计会直接导致系统卡顿甚至雪崩。本文结合实战经验，从慢查询定位、执行计划分析、索引优化到核心场景解决方案，给出可落地的全流程优化方案。
一、慢查询：性能瓶颈的第一重定位
慢查询是定位性能问题的核心入口，关键在于“精准捕捉”和“有效分析”。
1.1 开启慢查询日志（即时生效+永久配置）
临时开启（重启失效）：
-- 设置慢查询阈值（单位：秒，建议生产环境设0.5-1秒）SETGLOBALlong_query_time=0.5;-- 开启慢查询日志SETGLOBALslow_query_log='ON';-- 指定日志文件路径SETGLOBALslow_query_log_file='/var/log/mysql/slow.log';-- 记录未使用索引的查询（辅助定位索引失效）SETGLOBALlog_queries_not_using_indexes='ON';永久配置（修改my.cnf）：
[mysqld] slow_query_log = 1 slow_query_log_file = /var/log/mysql/slow.log long_query_time = 0.5 log_queries_not_using_indexes = 11.2 慢查询日志分析工具
推荐使用pt-query-digest（Percona Toolkit）或mysqldumpslow，前者分析维度更全面：
# 分析慢日志并输出TOP10耗时查询pt-query-digest /var/log/mysql/slow.log>slow_report.txt# 简易分析：取耗时最多的10条SELECT语句mysqldumpslow -s t -t10-g'select'/var/log/mysql/slow.log分析报告核心关注：执行次数、平均耗时、扫描行数、锁等待时间，这些指标直接指向优化优先级。
二、执行计划：读懂MySQL的“执行逻辑”
通过EXPLAIN关键字分析SQL执行计划，是判断索引是否生效、查询是否低效的核心手段。
2.1 核心字段解读
执行EXPLAIN SELECT * FROM orders WHERE user_id = 100 AND status = 'PAID';后，重点关注以下字段：
| 字段 | 核心意义 |
|---|---|
type | 访问类型（性能从优到劣：system > const > eq_ref > ref > range > index > ALL） |
key | 实际使用的索引（NULL表示未使用索引） |
rows | 预估扫描行数（数值越大，查询效率越低） |
Extra | 附加信息（Using filesort/Using temporary需优化，Using index是覆盖索引） |
2.2 关键判断标准
type为ALL（全表扫描）：优先优化，必须通过索引解决；rows远大于实际返回行数：索引选择性差或条件不合理；Extra出现Using filesort：排序未使用索引，需优化排序字段；Extra出现Using temporary：分组使用临时表，需优化分组字段。
三、索引失效：十大典型场景与解决方案
索引失效是慢查询的核心诱因，以下是实战中最常见的场景及优化方案：
| 失效场景 | 错误示例 | 优化方案 |
|---|---|---|
| 索引列参与计算/函数 | SELECT * FROM users WHERE YEAR(create_time) = 2023 | SELECT * FROM users WHERE create_time BETWEEN '2023-01-01' AND '2023-12-31' |
| 隐式类型转换 | SELECT * FROM logs WHERE user_id = '123'（user_id为INT） | SELECT * FROM logs WHERE user_id = 123 |
| LIKE以%开头 | SELECT * FROM user WHERE userId LIKE '%123' | 改用覆盖索引或LIKE '123%' |
| 违反最左前缀原则 | 联合索引(a,b,c)，查询WHERE b=2 AND c=3 | 调整查询条件为WHERE a=1 AND b=2 AND c=3 |
| OR连接无索引字段 | SELECT * FROM orders WHERE status='PAID' OR amount>1000 | 拆分为UNION ALL：SELECT * FROM orders WHERE status='PAID' UNION ALL SELECT * FROM orders WHERE amount>1000 |
| 索引列使用!=/<> | SELECT * FROM user WHERE age != 20 | 改用范围查询（如age < 20 OR age > 20），或业务层面过滤 |
| IS NULL/IS NOT NULL组合 | SELECT * FROM user WHERE name IS NOT NULL OR card IS NOT NULL | 拆分查询或单独为字段建索引 |
| 关联字段编码不一致 | 表A.name为utf8mb4，表B.name为utf8 | 统一关联字段编码为utf8mb4 |
| DELETE + IN子查询 | DELETE FROM account WHERE name IN (SELECT name FROM old_account) | 改为JOIN：DELETE a FROM account a JOIN old_account o ON a.name = o.name |
| 索引选择性过低 | 为性别、状态等低区分度字段建单独索引 | 合并为联合索引，或不建索引 |
四、索引设计：实战导向的最佳实践
索引设计的核心是“用最少的索引满足最多的查询”，遵循以下原则：
4.1 三星索引原则（实战核心）
- 一星：WHERE条件列加入索引；
- 二星：ORDER BY/GROUP BY列加入索引；
- 三星：SELECT列被索引覆盖（避免回表）。
示例：
-- 原始查询：SELECT user_id, username FROM users WHERE email = 'user@deepseek.com'-- 覆盖索引设计（包含查询所需所有列）ALTERTABLEusersADDINDEXidx_email_cover(email,user_id,username);4.2 联合索引设计技巧
- 高选择性字段在前（如用户ID > 状态 > 时间）；
- 等值查询字段在前，范围查询字段在后；
示例：
-- 查询：SELECT * FROM sales WHERE region='Asia' AND category='Tech' AND sale_date BETWEEN '2023-01-01' AND '2023-12-31' ORDER BY revenue DESC-- 最优联合索引ALTERTABLEsalesADDINDEXidx_region_category_date(region,category,sale_date);4.3 索引精简原则
- 避免冗余索引（如已有(a,b)，则(a)为冗余）；
- 大文本/Blob字段不建索引；
- 单表索引数控制在5个以内（减少插入/更新开销）。
五、核心场景优化：深分页、大表、排序分组
5.1 深分页优化（limit offset过大）
问题：SELECT * FROM account WHERE create_time > '2020-09-19' LIMIT 100000, 10需扫描100010行并回表，效率极低。
方案1：标签记录法（依赖自增ID）：
-- 记录上一页最后ID，直接定位SELECTid,name,balanceFROMaccountWHEREid>100000LIMIT10;方案2：延迟关联法（减少回表）：
SELECTacct1.id,acct1.name,acct1.balanceFROMaccount acct1INNERJOIN(SELECTa.idFROMaccount aWHEREa.create_time>'2020-09-19'LIMIT100000,10)ASacct2ONacct1.id=acct2.id;5.2 大表优化（单表千万级以上）
- 优先归档历史数据（如按年归档）；
- 水平分表（range范围/哈希取模）；
- 分区表（时间范围查询优先）：
CREATETABLElogs(idBIGINT,log_timeDATETIME,contentTEXT)PARTITIONBYRANGE(YEAR(log_time))(PARTITIONp2020VALUESLESS THAN(2021),PARTITIONp2021VALUESLESS THAN(2022),PARTITIONp2022VALUESLESS THAN(2023));5.3 ORDER BY/GROUP BY优化
- 排序/分组字段建索引（避免
Using filesort/Using temporary）； - GROUP BY禁用默认排序：
GROUP BY city ORDER BY NULL； - 调整排序缓冲区：
SET GLOBAL sort_buffer_size = 4M（根据业务调整）。
六、实战案例：DeepSeek订单系统慢查询重构
6.1 问题场景
SELECTo.order_id,o.amount,u.username,p.product_nameFROMorders oJOINusers uONo.user_id=u.user_idJOINproducts pONo.product_id=p.product_idWHEREo.status='COMPLETED'ANDo.create_timeBETWEEN'2023-01-01'AND'2023-12-31'ORDERBYo.create_timeDESCLIMIT1000;执行时间2.3秒，EXPLAIN显示orders表type=ALL（全表扫描），扫描行数50万。
6.2 优化方案
-- 原有索引（仅status）：ALTER TABLE orders ADD INDEX idx_status (status);-- 新三星索引（包含WHERE/ORDER BY/关联字段）ALTERTABLEordersADDINDEXidx_status_time_user_product(status,create_time,user_id,product_id);6.3 优化效果
orders表type=range（索引范围扫描），扫描行数1200；- 执行时间降至0.05秒，性能提升46倍。
七、运维保障：索引维护与监控
7.1 索引碎片整理
-- 重建索引（InnoDB）ALTERTABLEordersENGINE=InnoDB;-- 或优化表OPTIMIZETABLEorders;7.2 监控未使用索引
SELECTobject_schema,object_name,index_nameFROMperformance_schema.table_io_waits_summary_by_index_usageWHEREindex_nameISNOTNULLANDcount_star=0;定期删除未使用的索引，减少维护开销。
总结
MySQL性能优化的核心是“精准定位+最小化资源消耗”：
- 慢查询日志是定位问题的起点，EXPLAIN是分析执行逻辑的核心工具；
- 索引优化需避免失效场景，遵循三星索引和最左前缀原则；
- 核心场景（深分页、大表、排序分组）需针对性优化，优先减少扫描行数和回表操作；
- 优化后需持续监控，定期清理冗余索引和碎片。
