ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花要理解LIKE查询如何使用B+树索引，首先需明确两个核心前提：一是B+树索引的本质的是“有序的平衡树结构”，其索引键按字典序排列，叶子节点存储完整索引键（或行指针）并形成有序链表；二是LIKE查询的核心是“模糊匹配”，不同匹配模式（前缀、后缀、中间匹配）对索引的利用程度，完全取决于是否能借助B+树的“有序性”快速定位匹配范围。一、B+树索引的核心特性（为LIKE查询铺垫）B+树索引的核心价值的是“有序性”和“快速范围查找”，关键特性如下：索引键按字典序（如字母顺序、数字顺序）...

ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花MySQL中，二级索引（非聚簇索引）选择存储主键ID而非数据的物理地址，核心是由InnoDB引擎的聚簇索引架构决定的，本质是为了平衡数据一致性、存储效率和查询性能，同时适配事务与MVCC机制，具体原因可分为以下5点，结合引擎特性详细说明：1. 聚簇索引架构的必然选择（核心原因）InnoDB的核心设计是“索引即数据”，即聚簇索引（通常与主键同义）的叶子节点直接存储完整的行数据，而非指针或地址，整个表的数据是按照聚簇索引的顺序物理组织的，数据文件本身就是聚簇索引文件。如果二级索引...

ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花核心结论：Index Merge 是 MySQL 优化器在单表查询中，同时使用多个二级索引扫描并合并结果的访问方法，用于替代全表扫描，提升多条件查询效率。它仅作用于单表，基于二级索引（非聚簇索引），最终通过主键回表获取数据。一、三种核心算法与适用场景MySQL 支持 3 种合并策略，由优化器根据条件自动选择，可通过 EXPLAIN 精准识别。Intersection（交集）AND 连接，所有条件为等值匹配（=、IN）Using intersect(...)扫描多个索引，取主键...

ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花当SQL语句 select * from t where a = ? and b = ? 中，表t没有a和b的联合索引，只有a的单独索引（idx_a）和b的单独索引（idx_b）时，数据库优化器会根据「数据量、过滤性、索引成本」选择以下3种方式之一，核心逻辑是“选过滤性最好、成本最低的索引”，具体如下：1. 索引合并（Index Merge）—— 最优场景（过滤性均较好）这是最理想的情况，优化器会同时使用idx_a和idx_b两个单独索引，通过“交集”快速定位满足a=? an...

ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花一、什么是索引下推（ICP）索引下推（Index Condition Pushdown, 简称ICP）是MySQL 5.6及以上版本推出的一项查询优化技术，核心目标是减少存储引擎与MySQL服务器层之间的数据传输开销，提升非聚簇索引（二级索引）查询的效率，本质是将原本由服务器层负责的部分WHERE条件过滤操作，下推到存储引擎层执行，提前过滤掉不满足条件的数据，从而减少无效回表和数据传输次数。简单来说，ICP就像快递仓库的智能分拣系统：没有ICP时，仓库会将所有符合初步条件的包...

ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花在MySQL中，当需要删除百万级、千万级甚至亿级数据时，直接执行DELETE FROM 表名 WHERE 条件会引发严重的性能问题（如锁表、事务日志暴涨、数据库卡顿、业务中断），核心原因是InnoDB引擎的事务特性的和锁机制——一次性删除大量数据会触发全表扫描/大范围索引扫描，占用大量IO和CPU资源，同时持有表级锁或行级锁过久，阻塞其他读写操作。因此，需结合业务场景、数据特性，采用“低影响、分批次、可回滚”的策略，平衡删除效率与业务可用性。一、删除前核心准备（必做步骤）大数...

ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花不一定。索引并非“万能优化工具”，其对查询性能的影响取决于多种场景，核心结论如下：1. 索引能提高性能的场景（主流情况）当查询语句中包含索引列过滤条件（如WHERE子句、JOIN关联条件），且查询的数据量占表总数据量比例较小时（通常<10%-20%），索引能快速定位目标数据，避免全表扫描，显著提升查询速度。例如：给用户表的“手机号”列建索引，查询“手机号=138XXXX1234”的用户信息，能直接通过索引找到对应行，效率远高于全表遍历。2. 索引无法提高甚至降低性能的场...

ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花MySQL 中当表存在多个索引时，并非所有索引都会被生效，而是由优化器（Optimizer）基于特定规则和成本评估，选择“最优”索引执行查询。这一机制的核心是 基于成本的优化器（Cost-Based Optimizer, CBO），即优化器通过计算不同索引的执行成本，选择成本最低的方案，而非单纯依赖索引类型或定义顺序。理解这一机制，能帮助开发者设计更合理的索引、写出更高效的SQL，避免因索引选择不当导致的查询性能瓶颈。一、多索引选择的核心逻辑MySQL 优化器的核心目标是最小...

ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花MySQL索引是提升查询效率的核心手段，合理的索引设计能避免全表扫描、减少IO开销，而不合理的索引不仅无法优化性能，还会增加数据写入（插入、更新、删除）的成本，占用额外存储空间。设计索引需遵循“高效、实用、精简”的核心思路，具体原则如下：一、优先为高频查询字段建立索引索引的核心价值是加速查询，因此需优先为查询频率高、过滤性强的字段建立索引。比如用户表的user_id（主键，高频用于查询单个用户）、订单表的order_no（唯一索引，高频用于查询订单详情）、商品表的catego...

ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花MySQL InnoDB存储引擎采用B+树作为索引底层存储结构，核心遵循“索引组织表”（Clustered Index Organization）架构模式，数据与索引深度融合，不存在独立的数据存储文件，索引是数据存储的核心载体。其索引体系主要分为聚簇索引（主键索引）与非聚簇索引（二级索引）两大类，二者均基于B+树结构实现，但在存储架构、数据组织方式及查询逻辑上存在显著差异，共同构成InnoDB高效、稳定的索引查询体系，支撑数据库海量数据的高效检索。一、B+树基础结构（索引底层...

ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花在建立表的时候不建立索引，插入百万数据效率高一些适用于MySQL8亲测 -- ============================================= -- 1. 创建测试表（若已存在则先删除） -- ============================================= DROP TABLE IF EXISTS test_index_1; CREATE TABLE test_index_1 ( id INT AUTO_INCREMENT...

ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花MySQL 中索引与数据的存储位置，核心取决于所使用的存储引擎，其中 InnoDB 作为当前 MySQL 默认存储引擎，其索引与数据采用“索引组织表（IOT）”模式实现一体化存储，索引即是数据的组织载体，数据的存储位置与索引结构深度绑定；而 MyISAM 引擎采用“非索引组织表”模式，索引与数据分开存储，二者存储位置相互独立。本文重点围绕 InnoDB 引擎，详细解析索引与数据的存储位置、层级分布及关联机制，同时简要对比 MyISAM 引擎差异，确保内容的专业性与严谨性。一、...

ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花InnoDB 存储引擎采用“磁盘逻辑分层存储 + 内存缓冲优化 + 索引组织表（IOT）”的核心架构，在磁盘层面以表空间→段→区→页→行的五级逻辑结构实现数据分层管理，同时以聚簇索引 B+ 树作为核心数据组织形式，结合二级索引及内存优化组件，实现数据的高效读写与事务安全性保障。该设计模式既满足事务 ACID 特性的核心要求，又通过 B+ 树的有序性及内存缓冲机制，有效兼顾数据查询性能与存储效率。一、磁盘上的核心逻辑存储结构（五级分层）InnoDB 磁盘数据的组织遵循严格的层级...

ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花核心结论：在InnoDB默认配置（16KB数据页、BIGINT类型主键）下，3层B+树（聚簇索引）可存储数据量约为600万~2000万行；非聚簇索引因叶子节点不存储完整行数据，其存储量显著高于聚簇索引。计算的核心逻辑为：总存储行数 = 非叶子节点扇出数² × 单个叶子节点存储行数（3层B+树由根节点、中间层节点及叶子节点构成，其中根节点与中间层节点均为非叶子节点，且二者扇出数保持一致）。一、计算前提（InnoDB默认配置，适用于生产环境）存储量计算需明确以下4项核心参数，该参...