企业官网建设流程全解析

seo公司怎么推广宣传,做神马网站优化快速排,网站空间备份,wordpress图片分享插件下载地址兄弟们#xff0c;咱们搞技术的#xff0c;特别是和数据库打交道的#xff0c;有没有过这种经历#xff1f; 平时在开发环境写代码#xff0c;数据量就几百条#xff0c;那SQL写得叫一个“行云流水”#xff0c;各种 SELECT *#xff0c;各种 LEFT JOIN 连得飞起…兄弟们咱们搞技术的特别是和数据库打交道的有没有过这种经历平时在开发环境写代码数据量就几百条那SQL写得叫一个“行云流水”各种SELECT *各种LEFT JOIN连得飞起跑起来也是嗖嗖的。结果一上线真实数据量一上来刚开始还好过了一个月突然有一天半夜监控群炸了CPU 飚到 100%应用卡死连接池爆满。这时候老板站在你背后眼神犀利地盯着屏幕你冷汗直流手忙脚乱地打开数据库客户端除了机械式地给每个字段加索引是不是脑子里一片空白一定要记住老哥这句话你会写SQL但不代表你懂SQL。在 MySQL 8 的时代如果你不懂执行计划 (EXPLAIN)那你就是蒙着眼睛在高速公路上狂奔的 CRUD Boy撞墙是早晚的事。而一旦你掌握了它你就是拥有了“上帝视角”的架构师每一个慢查询在你眼里都是“裸奔”的。今天老哥我就结合RHEL 8 MySQL 8.0环境从最基础的字段解析到 MySQL 8 独有的EXPLAIN ANALYZE大杀器带你通盘掌握 SQL 调优的硬核技能。哪怕你是刚入行的新手跟着我把这篇文章啃完也能把 1 年经验用出 3 年的效果1 环境与数据准备 (不仅要看还要练)光说不练假把式。为了让大家能看到真实的优化效果优化器的“脾气”只有在数据量足够大时才能摸得准。咱们先来构造一个电商核心业务场景。环境CentOS/RHEL 8 MySQL 8.0.22 以上版本。建表脚本我们创建两张表sys_orders订单表和sys_order_detail明细表。CREATE DATABASE IF NOT EXISTS shop_core; USE shop_core; -- 订单主表 CREATE TABLE sys_orders ( order_id INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 订单ID, user_id VARCHAR(32) NOT NULL COMMENT 用户ID (注意是varchar), order_no VARCHAR(64) NOT NULL COMMENT 订单编号, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, status TINYINT NOT NULL DEFAULT 1 COMMENT 状态:1-待支付,2-已支付,3-发货,4-完成, total_amount DECIMAL(10,2) NOT NULL COMMENT 总金额, PRIMARY KEY (order_id), KEY idx_user_status (user_id, status), -- 联合索引 KEY idx_create_time (create_time) -- 时间索引 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单主表; -- 订单明细表 CREATE TABLE sys_order_detail ( item_id INT UNSIGNED NOT NULL AUTO_INCREMENT, order_id INT UNSIGNED NOT NULL, product_name VARCHAR(100) NOT NULL, price DECIMAL(10,2) NOT NULL, quantity INT NOT NULL, PRIMARY KEY (item_id), KEY idx_order_id (order_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单明细表;造数据存储过程咱们整一个存储过程快速往orders表插 10 万条数据detail表插 20 万条左右数据。这在生产环境只能算“毛毛雨”但足够演示执行计划了。-- 执行造数 (耐心等待十几秒) CALL generate_data(); -- 查看结果 mysql select count(*) from sys_orders; ---------- | count(*) | ---------- | 100000 | ---------- 1 row in set (0.01 sec) mysql select count(*) from sys_order_detail; ---------- | count(*) | ---------- | 199869 | ---------- 1 row in set (0.00 sec)2 读懂 EXPLAIN 的“天书” (核心字段全解析)数据有了现在我们随便跑一条 SQL看看它的“体检报告”。EXPLAIN SELECT * FROM sys_orders WHERE user_id U1001 AND status 2;输出大概长这样不同环境ID可能不同idselect_typetablepartitionstypepossible_keyskeykey_lenrefrowsfilteredExtra1SIMPLEsys_ordersNULLrefidx_user_statusidx_user_status131const,const1100.00NULL兄弟们别看列这么多作为 DBA平时我盯着看的主要是这 5 个核心指标type, key, key_len, rows, Extra。type: 访问类型 (性能的风向标)这是重中之重它告诉我们 MySQL 到底是怎么找数据的。我把常见的性能从好 - 坏排个序大家心里要有数system/const: 只有一行匹配。比如WHERE primary_key 1。这是性能的天花板快得飞起。eq_ref: 连表查询时前表的一行对应后表的唯一一行通常是主键或唯一索引关联。ref: 普通索引查找。比如我们上面的例子user_id不是唯一的可能搜出多条。range:这是我们优化的底线索引范围扫描。常见于,,BETWEEN,IN。如果你的 SQL 跑出了range通常是可以接受的。index(全索引扫描): ⚠️注意坑很多人以为看到index就是走了索引其实它是Full Index Scan。它扫描了 B 树的所有叶子节点只是比全表扫描少读了点数据因为索引文件通常比数据文件小。ALL(全表扫描): ☠️红色警报也是所谓的 Full Table Scan。MySQL 从硬盘头读到尾。如果是小表无所谓大表出现ALL基本就是因为没建索引或者索引失效。keykey_len: 到底用了哪个索引possible_keys: MySQL 觉得可能会用到的索引备胎。key: 最终实际选用的索引正宫。如果是NULL恭喜你全表扫描了。key_len: 索引使用的字节数。这个很有用比如我们的联合索引idx_user_status (user_id, status)。user_id是varchar(32)utf8mb4 编码下最长 32*4 2(变长长度) 130字节。status是tinyint1字节。如果key_len显示 130 或 131 (视是否允许NULL)说明只用了user_idstatus没用到这能帮你检查联合索引是不是只用了一部分。rowsfiltered: 只是个估算这里的坑最多老哥给你们总结几个最关键的。看懂这几个你基本就拿捏住了NULL(空): 不好不坏常规操作。这意味着查询走了索引但是索引无法覆盖所有查询的列所以必须回表Back to Table去主键聚簇索引里把原本的数据行捞出来。场景比如SELECT * FROM sys_orders WHERE user_id U1. 索引里只有user_id但你要*MySQL 只能拿着 ID 回去查正文。这是最常见的状态只要不是全表扫描typeALL通常可以接受。Using index: 好东西这叫“覆盖索引”。查询的字段全在索引树上直接从索引就能拿结果压根不用回表。场景SELECT user_id FROM sys_orders WHERE user_id U1. 这种性能极高是我们优化的终极目标。Using index condition: 值得鼓励的“小聪明”。这是 MySQL 5.6 引入的ICP (Index Condition Pushdown)特性。简单说就是 MySQL 把一部分过滤工作“下沉”到了存储引擎层。大白话解释本来存储引擎只管拿数据过滤是 Server 层的事。现在 Server 层把部分WHERE条件丢给存储引擎“兄弟你在查索引的时候顺便帮我把这个条件卡一下不符合的就别回表捞数据了省点 I/O。”结论比Using where强比Using index弱属于一种性能优化手段。Using where: 普普通通。说明存储引擎读上来数据后Server 层还得再过滤一遍。注意如果typeALL且有Using where说明你在全表扫描并过滤这种必须要优化如果typeref且有Using where通常问题不大。Using filesort: 红色警报说明 MySQL 无法利用索引顺序来排序必须在内存Sort Buffer或者磁盘里进行排序。比喻这就好比你去图书馆找书书架上的书是乱的你得把书全搬到地上自己一本本排好序才能给读者。极度消耗 CPU。Using temporary: 红色警报既然用到了临时表可能是内存的也可能是磁盘的性能通常好不到哪去。常见于GROUP BY、DISTINCT或复杂的UNION。看到这个一定要想办法优化索引或简化 SQL。3 MySQL 8 的大杀器EXPLAIN ANALYZE(不但要估算还要实测)以前我们用EXPLAIN就像是看地图估算时间“这路应该不堵大概 10 分钟”。但实际上可能路面塌陷你堵了 1 小时。EXPLAIN只是优化器的“预判”有时候它的成本计算Cost并不代表真实的执行时间。MySQL 8.0 引入了EXPLAIN ANALYZE。它不仅生成执行计划ule还会真正运行这条 SQL并告诉你每一步到底花了多久。单表操作实战演示让 MySQL “汗流浃背”为了看到真实的性能损耗我们来构造一个无法利用索引排序的场景。我们查询 3 月份以后的订单数据量大并且强制按“金额”排序无索引取前 20 条。-- 强制按 total_amount 排序让它必须在内存里排 EXPLAIN ANALYZE SELECT * FROM sys_orders WHERE create_time 2025-03-01 ORDER BY total_amount LIMIT 20;输出解读 (TREE 格式)| - Limit: 20 row(s) (cost10104.95 rows20) (actual time46.883..46.885 rows20 loops1) - Sort: sys_orders.total_amount, limit input to 20 row(s) per chunk (cost10104.95 rows99687) (actual time46.882..46.883 rows20 loops1) - Filter: (sys_orders.create_time TIMESTAMP2025-03-01 00:00:00) (cost10104.95 rows99687) (actual time0.030..32.416 rows83350 loops1) - Table scan on sys_orders (cost10104.95 rows99687) (actual time0.028..25.081 rows100000 loops1) |老哥带你深度拆解怎么看这棵树记住口诀从里往外看从下往上看先看缩进最深的。Table scan on sys_orders(最底层):发生了什么缩进最深MySQL 选择了全表扫描。数据说话rows100000(扫描了10万行)actual time...25.081。光是把这10万行数据从硬盘/内存里读一遍就花了25毫秒。Filter(过滤层):发生了什么拿着刚才读出来的10万行逐行比对create_time 2025-03-01。数据说话rows83350。说明大部分订单8.3万条都符合条件。这一步结束时时间累积到了32.416毫秒。Sort: sys_orders.total_amount(性能杀手):发生了什么这里的Sort就是传说中的Filesort因为total_amount没有索引MySQL 必须把这83350条数据扔到内存Sort Buffer里进行排序。数据说话注意看时间从 Filter 结束的 32ms 跳到了 Sort 结束的46.883ms。这意味着光是排序这一下就消耗了14毫秒的 CPU 时间细节limit input to 20 row(s) per chunk说明 MySQL 采用了优先队列排序Priority Queue不用给8万行全排序只维护最小的20个即可否则时间会更长。Limit(顶层):最后取前20条返回。[思考一下为什么有时候 EXPLAIN 显示走了索引比如 range但 EXPLAIN ANALYZE 里的 actual time 还是很长]老哥点拨EXPLAIN只能看到逻辑路径走了索引但它看不到物理成本。 如果你看到Index scan很快但像上面一样Sort这一层actual time暴涨说明瓶颈不在“找数据”而在“排序”。这时候加任何过滤索引都没用必须加包含排序字段的联合索引例如idx_time_amount(create_time, total_amount)才能彻底消灭这个Sort节点让性能直接起飞读懂多表关联 (JOIN) 的“套娃”结构**单表看完了咱们来看看多表关联。这可是小白最容易晕的地方。在 MySQL 8 的TREE格式里JOIN 就像是一个“套娃”或者“嵌套循环”。实战演示我们要查询“用户 U1 的所有订单详情”。这需要关联sys_orders和sys_order_detail。EXPLAIN ANALYZE SELECT d.* FROM sys_orders o JOIN sys_order_detail d ON o.order_id d.order_id WHERE o.user_id U1;输出解读 (TREE 格式)- Nested loop inner join (cost12.50 rows5) (actual time0.055..0.120 rows5 loops1) - Index lookup on o using idx_user_status (user_idU1) (cost2.50 rows2) (actual time0.045..0.050 rows2 loops1) - Index lookup on d using idx_order_id (order_ido.order_id) (cost2.10 rows2) (actual time0.015..0.020 rows2.5 loops2)老哥带你深度拆解看完这个树你得学会找“谁是老司机驱动表”“谁是乘客被驱动表”。Nested loop inner join(最外层):这告诉我们MySQL 决定用嵌套循环连接 (NLJ)的方式来处理。你可以把它理解为两层for循环。Index lookup on o(驱动表/外层循环):位置缩进较少排在上面。这就是驱动表。解读MySQL 先去sys_orders(别名 o) 表里找user_idU1的记录。数据rows2 loops1。找到了 2 个订单。注意这里的loops1说明这个动作只做了一次。Index lookup on d(被驱动表/内层循环):位置缩进更深排在下面。这就是被驱动表。关键点注意看loops2为什么是 2核心逻辑因为驱动表订单表找到了 2 条记录所以内层循环就要执行 2 次。拿着订单 A 的 ID 去明细表查一次再拿着订单 B 的 ID 去明细表查一次。性能公式被驱动表的查询成本×驱动表的行数。[思考一下如果驱动表扫出了 1 万条数据会对被驱动表产生什么影响]老哥点拨那就是灾难如果驱动表有 1 万行被驱动表就要被查询 1 万次。这时候被驱动表的关联字段order_id必须要有索引否则就是做 1 万次全表扫描数据库直接宕机4 实战演练常见“坑”与优化方案知道了原理咱们来看几个平时开发中最容易踩的坑。场景一联合索引的“最左前缀”原则失效坑爹 SQL-- 索引是 (user_id, status)但我跳过了 user_id 直接查 status EXPLAIN SELECT * FROM sys_orders WHERE status 1; ----------------------------------------------------------------------------------------------------------------- | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | ----------------------------------------------------------------------------------------------------------------- | 1 | SIMPLE | sys_orders | NULL | ALL | NULL | NULL | NULL | NULL | 99687 | 10.00 | Using where | -----------------------------------------------------------------------------------------------------------------结果type: ALL。分析联合索引就像是“按姓氏、再按名字”排序的电话簿。你现在只给我一个名字status不给姓氏user_id我没法查只能从头翻到尾。还有一种坑在索引列上做运算。EXPLAIN SELECT * FROM sys_orders WHERE LEFT(user_id, 2) U1; ----------------------------------------------------------------------------------------------------------------- | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | ----------------------------------------------------------------------------------------------------------------- | 1 | SIMPLE | sys_orders | NULL | ALL | NULL | NULL | NULL | NULL | 99687 | 100.00 | Using where | -----------------------------------------------------------------------------------------------------------------结果type: ALL。优化只要对索引字段用了函数索引立马失效。改成LIKE U1%就可以走range索引了。场景二隐式转换导致的灾难坑爹 SQL-- user_id 是 VARCHAR 类型但我查询时没加单引号用了数字 EXPLAIN SELECT * FROM sys_orders WHERE user_id 1001; ------------------------------------------------------------------------------------------------------------------- | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | ------------------------------------------------------------------------------------------------------------------- | 1 | SIMPLE | sys_orders | NULL | ALL | idx_user_status | NULL | NULL | NULL | 99687 | 10.00 | Using where | -------------------------------------------------------------------------------------------------------------------结果type: ALL且Extra显示Using where。分析这是新手最容易犯的错MySQL 发现类型对不上会偷偷把user_id转成数字进行比较相当于执行了CAST(user_id AS SIGNED)。一旦在索引列上加了隐式函数索引全废优化乖乖加上单引号user_id 1001。场景三ORDER BY导致的Using filesort坑爹 SQL-- 有 user_id 索引但我非要按 total_amount 排序 EXPLAIN SELECT * FROM sys_orders WHERE user_id U1001 ORDER BY total_amount; --------------------------------------------------------------------------------------------------------------------------------- | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | --------------------------------------------------------------------------------------------------------------------------------- | 1 | SIMPLE | sys_orders | NULL | ref | idx_user_status | idx_user_status | 130 | const | 2 | 100.00 | Using filesort | ---------------------------------------------------------------------------------------------------------------------------------结果Extra出现Using filesort。分析虽然user_id走了索引但查出来的数据是按user_id排序的不是按total_amount排序的。MySQL 只能把数据拿出来在内存里重排。优化如果这个业务非常高频建立联合索引(user_id, total_amount)。这样查出来的数据本身就是按金额排序的直接取就行省去了排序的 CPU 消耗。场景四深分页问题 (LIMIT 100000, 10)坑爹 SQLEXPLAIN SELECT * FROM sys_orders ORDER BY create_time LIMIT 90000, 10; -------------------------------------------------------------------------------------------------------------------- | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | -------------------------------------------------------------------------------------------------------------------- | 1 | SIMPLE | sys_orders | NULL | ALL | NULL | NULL | NULL | NULL | 99687 | 100.00 | Using filesort | --------------------------------------------------------------------------------------------------------------------结果type: ALL或者index扫描行数巨大。分析MySQL 需要查出 90010 条记录抛弃前 90000 条只取最后 10 条。这在数据量大时是灾难。优化方案延迟关联 (Late Row Lookup)EXPLAIN SELECT * FROM sys_orders t1 JOIN ( SELECT order_id FROM sys_orders ORDER BY create_time LIMIT 90000, 10 ) t2 ON t1.order_id t2.order_id; ------------------------------------------------------------------------------------------------------------------------------------- | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | ------------------------------------------------------------------------------------------------------------------------------------- | 1 | PRIMARY | derived2 | NULL | ALL | NULL | NULL | NULL | NULL | 90010 | 100.00 | NULL | | 1 | PRIMARY | t1 | NULL | eq_ref | PRIMARY | PRIMARY | 4 | t2.order_id | 1 | 100.00 | NULL | | 2 | DERIVED | sys_orders | NULL | index | NULL | idx_create_time | 5 | NULL | 90010 | 100.00 | Using index | -------------------------------------------------------------------------------------------------------------------------------------原理解析子查询只查order_id主键可以利用覆盖索引不需要回表速度极快。拿到 10 个 ID 后再回表去拿完整的*数据。这样就把 90000 次回表 I/O 变成了 10 次。场景五多表关联时的“隐形杀手” (被驱动表无索引)**兄弟们JOIN 慢90% 的原因是因为被驱动表Joined Table的连接列上没有索引。但在 MySQL 8 中情况变了以前没有索引会用“Block Nested Loop (BNL)”慢得像蜗牛现在 MySQL 8 引入了Hash Join。坑爹 SQL (模拟现场)假设我们手贱把sys_order_detail表上的idx_order_id索引给删了或者连接条件写错了导致无法走索引。-- 假设 sys_order_detail 的 order_id 上没有索引 EXPLAIN ANALYZE SELECT * FROM sys_orders o JOIN sys_order_detail d ON o.order_id d.order_id;MySQL 8 的“救命”输出- Inner hash join (no condition) (costxxxx rowsxxxx) (actual time...) - Table scan on d (cost...) (actual time...) - Hash - Table scan on o (cost...) (actual time...)分析与优化现象你会看到Inner hash join。这意味着 MySQL 放弃了循环查找而是把其中一张表通常是小表全部读入内存构建一个哈希表然后扫描另一张大表去碰撞。它是好事还是坏事相比于 MySQL 5.7 的 BNLHash Join 是巨大的进步。它让本来要跑几个小时的烂 SQL可能几分钟就跑完了。但是它依然意味着全表扫描。它需要把两张表都读一遍。优化方案别指望 Hash Join 救命。给被驱动表的连接字段order_id加上索引让它变回Nested loop inner join配合Index lookup。对比Hash Join 是全量扫描扫 20 万行加了索引后的 NLJ 可能只需要扫描几十行。这中间的 I/O 差距是数量级的。老哥心法小表驱动大表原则依然适用但在 MySQL 8 优化器面前它会自动帮你选谁是小表你不用太纠结LEFT JOIN还是RIGHT JOIN除非业务逻辑限制。死死盯住被驱动表只要 EXPLAIN 里出现了Hash Join或者Block Nested Loop第一时间检查关联字段有没有索引或者关联字段的数据类型是否一致避免隐式转换。总结兄弟们写到这大概的套路你们应该都看明白了。EXPLAIN是我们手里的静态地图而 MySQL 8 的EXPLAIN ANALYZE则是实时导航能告诉你哪里堵车。最后老哥再送大家三句SQL 调优心法这是我这十几年踩坑换来的不要过度优化只有慢查询才需要优化。如果一个报表 SQL 一天只跑一次跑 2 秒和 0.1 秒对业务没区别别为了它把索引搞得巨复杂导致插入数据变慢。索引不是越多越好索引是把双刃剑。查询快了增删改DML必然变慢因为要维护索引树。一张表的索引最好不要超过 5 个。核心关注点RowsxCost所有的优化手段加索引、改写法最终目的都是为了减少 MySQL 扫描的行数。扫描的数据越少I/O 就越少速度自然就快。