企业官网建设流程全解析

北京高端网站建设价格,windows优化大师怎么使用,小程序搭建工具,重庆做模块网站一、MySQL进阶1. 索引在数据库性能优化中#xff0c;索引是提升查询效率的核心手段。1.1 使用规则1. 验证索引的效率‘通过指令查询#xff0c;我们准备的数据库里面有1000w条数据。该指令可以将因为数据量太大而导致输出的格式变形的问题根据sn字段进行查询#xff0c;执行…一、MySQL进阶1. 索引在数据库性能优化中索引是提升查询效率的核心手段。1.1 使用规则1. 验证索引的效率‘通过指令查询我们准备的数据库里面有1000w条数据。该指令可以将因为数据量太大而导致输出的格式变形的问题根据sn字段进行查询执行的效率如下用时20多秒效率极其低下原因很简单通过主键id查询有默认的索引查询而sn并没有建立索引效率极其低下在庞大的数据量面前。通过指令创建索引再次执行相同的sql查询语句对比耗时情况20s对比0.01s根本不是一个数量级的优化2. 最左前缀法则核心概念当创建联合索引(a, b, c)时查询条件必须从最左列开始且连续不能跳过中间列否则后续列索引失效详细示例-- 创建联合索引 CREATE INDEX idx_a_b_c ON table(a, b, c); -- 有效查询使用最左前缀 SELECT * FROM table WHERE a 1; -- 有效 SELECT * FROM table WHERE a 1 AND b 2; -- 有效 SELECT * FROM table WHERE a 1 AND b 2 AND c 3; -- 有效 -- 无效查询跳过中间列 SELECT * FROM table WHERE b 2; -- 无效 SELECT * FROM table WHERE a 1 AND c 3; -- 无效b列缺失生动类比想象一本电话簿按姓氏排序姓氏相同再按名字排序。查找姓张的人只用最左列姓氏→ ✅ 有效查找名叫三的人只用名字跳过了姓氏→ ❌ 无效。3. 范围查询问题现象在联合索引中如果使用、等范围查询范围查询右侧的列索引会失效。案例分析-- 创建联合索引 CREATE INDEX idx_a_b_c ON table(a, b, c); -- 有效查询 SELECT * FROM table WHERE a 1 AND b 2 AND c 3; -- 索引全部有效 -- 无效查询范围查询后列失效 SELECT * FROM table WHERE a 1 AND b 2 AND c 3; -- c列失效Explain结果key: idx_a_b_c key_len: 49 (仅a、b列有效) Extra: Using where解决方案将范围查询放在联合索引的最后尽量使用和替代和4. 索引失效情况a. 索引列运算-- 索引失效 SELECT * FROM users WHERE YEAR(create_time) 2023; -- 优化后 SELECT * FROM users WHERE create_time 2023-01-01 AND create_time 2024-01-01;b. 字符串不加引号-- 索引失效status为varchar类型 SELECT * FROM users WHERE status 0; -- 优化后 SELECT * FROM users WHERE status 0;c. 模糊查询-- 索引失效 SELECT * FROM users WHERE name LIKE %张; -- 优化后 SELECT * FROM users WHERE name LIKE 张%;d. or连接的条件-- 索引失效可能不使用索引 SELECT * FROM users WHERE status 0 OR age 30; -- 优化后使用UNION SELECT * FROM users WHERE status 0 UNION ALL SELECT * FROM users WHERE age 30;e. 数据分布影响当索引列的值分布极不均匀如性别字段只有男和女索引效果会大打折扣优化考虑使用覆盖索引或调整查询策略5. sql提示MySQL支持使用SQL提示强制使用特定索引SELECT * FROM table USE INDEX(idx_a_b_c) WHERE a 1 AND b 2;使用场景当优化器选择的索引不是最优时可以使用提示强制指定索引。6. 覆盖索引和回表查询回表查询定义通过辅助索引定位主键再通过聚集索引获取完整行数据过程扫描两遍索引树性能影响比直接扫描聚集索引慢案例user表有id主键、name索引、age字段SELECT * FROM user WHERE name 张三; -- 需要回表查询覆盖索引定义查询所需的所有字段都包含在索引中无需回表标识EXPLAIN的Extra字段显示Using index优化案例-- 原查询回表 SELECT * FROM user WHERE name 张三; -- 优化后覆盖索引 SELECT id, name FROM user WHERE name 张三;通过将查询字段限制为索引中已有的字段避免了回表查询。为什么要避免使用selcet*因为返回所有的字段极易出现回表查询影响查询效率。除非你有一个联合索引包含所有的字段。7. 前缀索引适用场景字符串字段长度过长如VARCHAR(255)字段值前缀有足够区分度-- 前缀长度为10 CREATE INDEX idx_name_prefix ON users(name(10));优势减少索引大小提高索引效率风险前缀长度过短可能导致索引区分度低最佳实践通过SELECT COUNT(DISTINCT LEFT(name, 10)) / COUNT(*) FROM users;计算区分度确保前缀长度足够。8. 单列索引和联合索引的选择问题选择原则场景推荐索引类型说明单条件高频查询单列索引简单直接效率高多条件组合查询联合索引符合最左前缀原则查询字段与索引字段匹配覆盖索引避免回表性能最优长字符串字段前缀索引减少索引大小决策流程分析查询模式收集SQL日志确定高频查询条件评估字段区分度确保索引字段有足够区分度考虑查询字段如果查询需要返回的字段在索引中优先考虑覆盖索引权衡存储与性能避免过度索引平衡存储空间与查询性能-- 情景查询条件为 (category_id, price, status) -- 方案1创建三个单列索引 CREATE INDEX idx_category ON products(category_id); CREATE INDEX idx_price ON products(price); CREATE INDEX idx_status ON products(status); -- 方案2创建联合索引 CREATE INDEX idx_category_price_status ON products(category_id, price, status); -- 方案3创建覆盖索引 CREATE INDEX idx_category_price_status_cover ON products(category_id, price, status) INCLUDE (name, description);分析方案2比方案1好因为联合索引可以利用最左前缀原则方案3比方案2更好因为覆盖索引可以避免回表查询。结语索引优化的系统思维索引优化不是简单的加索引而是一个系统化的过程先分析通过慢查询日志和EXPLAIN分析问题SQL再设计根据查询模式和字段特性设计合适索引后验证通过实测和EXPLAIN确认优化效果持续优化定期分析索引使用情况清理冗余索引金句索引不是越多越好而是越合适越好。 —— 一位资深DBA