企业官网建设流程全解析

如何去建设一个企业网站,网站空间备案流程,泉州网站开发公司,全国广电网络公司排名EXPLAIN 关键字#xff1a;MySQL 查询执行计划的 “透视镜”你想深入了解EXPLAIN关键字#xff0c;它是 MySQL 中分析查询性能、排查索引失效、优化 SQL 的核心工具 —— 通过EXPLAIN可以 “看透” MySQL 优化器如何执行你的 SQL 语句#xff0c;包括是否使用索引、扫描行数…EXPLAIN 关键字MySQL 查询执行计划的 “透视镜”你想深入了解EXPLAIN关键字它是 MySQL 中分析查询性能、排查索引失效、优化 SQL 的核心工具 —— 通过EXPLAIN可以 “看透” MySQL 优化器如何执行你的 SQL 语句包括是否使用索引、扫描行数、连接方式等关键信息无需实际执行查询就能定位性能问题。下面我会从基本用法→输出字段详解→实战案例→进阶用法四个维度把EXPLAIN讲透让你能独立分析任意 SQL 的执行计划。一、EXPLAIN 基本用法1. 核心作用显示 MySQL 执行 SQL 时的执行计划而非执行结果告诉我们SQL 将如何扫描表、是否使用索引、扫描多少行、表之间如何连接等支持SELECT、DELETE、INSERT、UPDATEMySQL 8.0最常用的是SELECT。2. 基础语法-- 最基础用法分析SELECT语句 EXPLAIN SELECT * FROM user WHERE name 张三; -- 简写效果相同 DESC SELECT * FROM user WHERE name 张三; -- MySQL 8.0支持分析UPDATE/DELETE EXPLAIN UPDATE user SET age 21 WHERE id 1;执行后会返回一个表格通常 1 行或多行对应多表连接每行包含 12 个字段MySQL 5.7每个字段都有明确的性能含义。二、EXPLAIN 输出字段详解按重要性排序为了方便理解先给出一个典型的执行计划示例EXPLAIN SELECT id, name FROM user WHERE name 张三;输出结果核心字段idselect_typetabletypepossible_keyskeykey_lenrefrowsExtra1SIMPLEuserrefidx_nameidx_name62const2Using index下面逐个解析每个字段的含义重点标注核心关注项1. id查询的执行顺序标识含义表示查询中执行子查询 / 表连接的顺序数字越大越先执行规则相同 id按从上到下顺序执行多表连接不同 idid 值越大执行优先级越高NULL表示这是一个临时表 / 汇总结果如GROUP BY的临时表。示例-- 子查询id2先执行再执行id1 EXPLAIN SELECT * FROM user WHERE id (SELECT id FROM order WHERE order_no O123);2. select_type查询类型判断查询复杂度核心值说明按常见程度排序值含义SIMPLE简单查询无子查询、无 UNION最常见PRIMARY主查询包含子查询 / UNION 时外层查询的类型SUBQUERY子查询内层查询不依赖外层DERIVED派生表FROM 中的子查询MySQL 会先执行并生成临时表UNIONUNION 中的第二个及以后的查询UNION RESULTUNION 的最终结果集3. table当前行对应的表 / 临时表显示执行计划对应的表名如user、order若为派生表显示derivedNN 为 id 值若为 UNION 结果显示unionM,NM、N 为 id 值。4. type访问类型核心判断索引是否生效含义MySQL 扫描表中数据的方式是判断查询性能的最核心指标从优到劣排序如下类型含义性能等级说明system表只有 1 行数据系统表极致优化几乎遇不到最优特殊情况比 const 更好const通过主键 / 唯一索引查询最多匹配 1 行最优如WHERE id 1eq_ref多表连接时被驱动表通过主键 / 唯一索引匹配如JOIN t2 ON t1.idt2.id优秀关联查询的理想类型ref通过非唯一索引匹配返回多行如WHERE name 张三良好索引生效的常见类型ref_or_null类似 ref但包含 NULL 值查询如WHERE name 张三 OR name IS NULL良好略逊于 refrange索引范围扫描如WHERE id BETWEEN 1 AND 10、IN (1,2,3)一般索引生效但扫描范围较大index扫描整个索引树未回表如覆盖索引较差比 ALL 好但仍扫描全索引ALL全表扫描Full Table Scan最差索引失效性能暴跌核心判断✅ 理想情况const/eq_ref/ref索引高效生效⚠️ 需要优化range尽量缩小范围❌ 必须优化index/ALL索引失效全表 / 全索引扫描。5. possible_keys可能使用的索引含义MySQL 优化器认为该查询可能用到的索引列表仅为候选不一定实际使用若为NULL表示没有可用的索引大概率会全表扫描。6. key实际使用的索引核心含义MySQL 优化器最终选择的索引名称若为NULL表示未使用任何索引索引失效重点possible_keys有值但key为NULL说明优化器判断走索引成本更高主动放弃如匹配行数太多。7. key_len使用的索引长度字节含义表示 MySQL 使用的索引字段的总长度可用于判断联合索引的生效范围计算规则示例varchar(20)utf820×3 2字符串长度标识 62 字节int4 字节联合索引idx_name_age(name, age)若key_len66624说明两个字段都生效若 62说明仅 name 生效。8. ref与索引比较的列 / 常量含义表示与索引字段匹配的内容分为两种const匹配常量如WHERE name 张三 张三 是常量表名。字段名多表连接时匹配另一张表的字段如t1.name t2.name若为NULL表示没有使用等值匹配如范围查询。9. rows预估扫描行数核心含义MySQL 优化器预估的、执行查询需要扫描的行数不是实际行数数值越小越好行数越多说明需要扫描的数据越多性能越差注意该值是基于表的统计信息估算的可能与实际有偏差可通过ANALYZE TABLE 表名更新统计信息。10. Extra额外信息核心含义补充说明执行计划的关键细节常见重要值如下值含义优化指导Using index使用覆盖索引无需回表性能极佳理想状态尽量保留Using where先扫描数据再用 WHERE 过滤可能索引失效需检查是否能用索引过滤Using index condition索引条件下推ICP先通过索引过滤部分数据减少回表优化器自动优化正常Using filesort需额外排序未使用索引排序性能差必须优化加排序字段索引Using temporary需创建临时表如 GROUP BY/ORDER BY 字段无索引性能极差必须优化加联合索引Using join buffer多表连接时使用连接缓冲区未用索引连接需优化连接字段的索引Impossible WHEREWHERE 条件永远为假如WHERE 10无数据返回检查 SQL 逻辑Select tables optimized away聚合函数如 COUNT (*)直接通过索引统计获取无需扫描数据最优状态三、EXPLAIN 实战案例手把手分析案例 1索引生效理想情况-- 表结构user(id PK, name 索引, age) EXPLAIN SELECT id, name FROM user WHERE name 张三;输出核心字段分析typekeyrowsExtra结论refidx_name2Using index索引生效覆盖索引无回表分析typeref使用非唯一索引匹配索引生效keyidx_name实际使用 name 索引ExtraUsing index覆盖索引无需回表rows2仅扫描 2 行性能优秀。案例 2索引失效全表扫描EXPLAIN SELECT * FROM user WHERE DATE(create_time) 2025-12-27;输出核心字段分析typekeyrowsExtra结论ALLNULL1000Using where索引失效全表扫描分析typeALL全表扫描索引失效keyNULL未使用任何索引rows1000预估扫描 1000 行性能差原因对索引字段create_time使用了DATE()函数导致索引失效。案例 3联合索引部分生效-- 联合索引idx_a_b_c(a,b,c) EXPLAIN SELECT * FROM user WHERE a 1 AND c 3;输出核心字段分析keykey_lenExtra结论idx_a_b_c4Using where仅 a 字段的索引生效c 失效分析keyidx_a_b_c使用了联合索引但key_len4仅 a 字段的长度原因破坏了最左前缀原则跳过 b 直接用 c导致 c 的索引失效优化调整查询条件为a1 AND b IS NOT NULL AND c3或修改联合索引为idx_a_c。四、EXPLAIN 进阶用法1. EXPLAIN EXTENDEDMySQL 5.6额外输出filtered字段过滤百分比表示经过 WHERE 过滤后剩余的行数比例可通过SHOW WARNINGS查看优化器改写后的 SQL比如隐式转换、条件简化EXPLAIN EXTENDED SELECT * FROM user WHERE phone 13800138000; SHOW WARNINGS; -- 会显示优化器将phone13800138000改为phoneCAST(13800138000 AS CHAR)2. EXPLAIN FORMATJSON结构化输出输出 JSON 格式的执行计划包含更详细的成本计算如cost_info、rows_examined_per_scan适合深度分析3. 分析多表连接多表连接时EXPLAIN会返回多行每张表一行按id和执行顺序分析EXPLAIN SELECT * FROM user u JOIN order o ON u.id o.user_id WHERE u.name 张三;重点关注驱动表先执行的表的type是否为ref/const被驱动表的type是否为eq_ref主键 / 唯一索引连接避免typeALL的表出现在连接的外层会导致全表扫描后再连接。总结EXPLAIN 核心价值无需执行 SQL就能查看优化器的执行计划定位索引失效、全表扫描、临时表 / 文件排序等性能问题核心关注字段type访问类型避免 ALL/index、key实际使用的索引避免 NULL、rows预估扫描行数越小越好、Extra是否有 Using filesort/Using temporary使用流程写 SQL → EXPLAIN 分析 → 定位问题如 typeALL、keyNULL → 优化加索引 / 改 SQL → 重新 EXPLAIN 验证。