MySQL查询优化需四步：慢查询定位→执行计划解读→索引与语句优化→系统资源验证；先启用慢日志分析瓶颈，再用EXPLAIN查看type/key/rows/Extra，遵循最左前缀建索引，避免函数操作字段，最后检查缓冲池命中率。
MySQL 查询执行时间长，核心要从 慢查询定位 → 执行计划解读 → 索引与语句优化 → 系统资源验证 四步入手，不能只看“花了多久”，得知道“卡在哪”。
开启并分析慢查询日志
这是发现性能问题的第一手线索。默认慢查询日志是关闭的，需手动启用：
- 在 my.cnf 中添加：
slow_query_log = ONslow_query_log_file = /var/log/mysql/mysql-slow.loglong_query_time = 1（单位秒，建议设为 0.5～1，便于捕获真实瓶颈） - 重启 MySQL 或动态启用：
SET GLOBAL slow_query_log = ON;SET GLOBAL long_query_time = 1; - 用
mysqldumpslow工具快速汇总（例如 top 10 最慢查询）：mysqldumpslow -s t -t 10 /var/log/mysql/mysql-slow.log
用 EXPLAIN 看懂执行计划
对慢查询加 EXPLAIN 前缀，重点观察以下几列：
kashen-mysql DDLtoExcel
下载
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
-
type：值越靠前性能越好（system > const > eq_ref > ref > range > index > ALL）。出现
ALL表示全表扫描，大概率缺索引 -
key：实际使用的索引名。为
NULL说明没走索引 - rows：预估扫描行数。远大于结果集行数（如 SELECT 返回 10 行，但 rows=50000），说明过滤效率低
-
Extra：警惕
Using filesort（排序未走索引）、Using temporary（用了临时表）、Using join buffer（连接缓存回退到内存/磁盘）
检查索引有效性与 SQL 写法
很多慢查表面是语句问题，根子在索引没建对或被隐式失效：
- 复合索引要遵循 最左前缀原则：WHERE 条件中跳过左边字段，右边字段就无法使用索引（如索引 (a,b,c)，WHERE b=2 AND c=3 不走索引）
- 避免在 WHERE 字段上做函数或运算：
❌WHERE YEAR(create_time) = 2024→ 改为 ✅WHERE create_time >= '2024-01-01' AND create_time - 少用
SELECT *，尤其大表关联时；明确需要字段，减少网络传输和临时表开销 - 分页深翻慎用
LIMIT 10000,20：改用游标方式（如记录上一页最大 ID）或延迟关联
结合系统指标交叉验证
SQL 本身没问题，也可能是资源瓶颈拖慢执行：
- 查当前活跃会话与锁等待：
SHOW PROCESSLIST;SELECT * FROM information_schema.INNODB_TRX;SELECT * FROM information_schema.INNODB_LOCK_WAITS; - 观察 InnoDB 状态关键指标：
SHOW ENGINE INNODB STATUS\G→ 关注ROW OPERATIONS、SEMAPHORES、TRANSACTIONS部分 - 确认缓冲池命中率（理想 > 99%）：
(Innodb_buffer_pool_read_requests - Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests
