MySQL索引给拿捏住了

本篇文章给大家带来了关于mysql的相关知识,其中主要介绍了关于mysql索引的相关问题,包括了索引按照逻辑功能划分、按照物理实现划分、按照字段个数划分等索引类型问题,希望对大家有帮助。

MySQL索引给拿捏住了

推荐学习:mysql教程

在 SQL 优化中,索引是至关重要的一环,能给查询效率带来质的飞跃,但是索引并不是万能的,不合理的索引设计甚至会拖慢查询效率。

索引定义

索引是一种专门用于帮助 SQL 高效获取数据的数据结构,一个常用的例子是,索引类似于一本书的目录,可以快速对特定值进行定位和查找,从而大大加快数据查询的效率。实际上,索引也是一张表,这张表保存了主键与索引字段,并指向实体表的记录(类似指针)。

索引优缺点

优点

索引大大减小了服务器需要扫描的数据量索引可以帮助服务器避免排序和临时表索引可以将随机IO变成顺序IO索引对于InnoDB(对索引支持行级锁)非常重要,InnoDB仅对需要访问的元组加锁,而索引能够减少InnoDB访问的元组数。如果查询不能使用索引,MySQL会进行全表扫描,并锁住每一个元组,不管是否真正需要。

缺点

虽然索引大大提高了查询速度,同时却会降低更新表的速度。因为更新表时,MySQL不仅要保存数据,还要保存索引文件。因此,对应更新非常频繁的字段,通常不建议使用索引。建立索引会占用磁盘空间。如果某个数据列包含许多重复的内容,为它建立索引效果就很差,这个性质称为索引的选择性:不重复的索引值和数据表中的记录总数的比值。索引的选择性越高则查询效率越高。比如对性别字段建立索引,一百万条数据,只有男女两种可能,索引选择性为五十万分之一,索引效果就很差对于非常小的表,索引意义不大,大部分情况下简单的全表扫描更高效。

因此应该只为最经常查询和最经常排序的数据列建立索引。MySQL里同一个数据表里的索引总数限制为16个。

索引类型

按功能逻辑划分

从功能逻辑来划分,索引主要分为 普通索引、唯一索引、主键索引和全文索引

普通索引

最基本的索引,它没有任何限制。普通索引(由关键字KEY或INDEX定义的索引)的唯一任务是加快对数据的访问速度。因此,应该只为那些最经常出现在查询条件(WHERE column = …)或排序条件(ORDER BY column)中的数据列创建索引。

普通索引的创建有三种方式。

# 创建索引CREATE INDEX idx_username ON user_tbl(username);# 对于字符串字段,可以手动指定长度,如 user_tbl(username(5)),表示只用前五个字符来做索引,可以进一步加快查询效率,索引长度要小于字段长度# 修改表结构ALTER TABLE user_tbl ADD INDEX idx_username (username)# 创建表的时候直接指定,如CREATE TABLE user_tbl( ID INT NOT NULL, username VARCHAR(16) NOT NULL, INDEX idx_username (username) );

删除索引

DROP INDEX idx_username ON user_tbl;

查看索引

SHOW INDEX FROM user_tbl;

唯一索引

它与前面的普通索引类似,不同的就是:普通索引允许被索引的数据列包含重复的值。而唯一索引列的值必须唯一,但允许有空值。如果是组合索引,则列值的组合必须唯一。

唯一索引的创建跟普通索引类似:

#创建索引CREATE UNIQUE INDEX idx_username ON user_tbl(username);# 修改表结构ALTER TABLE user_tbl ADD UNIQUE idx_username (username)# 创建表的时候直接指定CREATE TABLE user_tbl( ID INT NOT NULL, username VARCHAR(16) NOT NULL, UNIQUE idx_username (username) );

主键索引

它是一种特殊的唯一索引,不允许有空值。一张表只能有一个主键,一般是在建表的时候同时创建。

CREATE TABLE user_tbl( ID INT NOT NULL, username VARCHAR(16) NOT NULL, PRIMARY KEY(ID) );

与之类似的是外键索引,如果为某个外键字段定义了一个外键约束条件,MySQL就会定义一个内部索引来帮助自己以最有效率的方式去管理和使用外键约束条件。

全文索引

在上一篇文章 MySQL 基础语法 中,我们说过如果使用了 LIKE + % 开头,就索引会失效,那么当我们需要前后都模糊搜索的需求(如 LIKE ‘%hello%’),就需要使用全文索引,需要注意的是,Innodb 只有在 5.6 版本之后才支持全文索引。

全文索引的创建和删除:

# 创建的两种方法CREATE FULLTEXT INDEX idx_name ON tbl_name(field_name);ALTER TABLE tbl_name ADD FULLTEXT INDEX idx_name(field_name);# 删除的两种方法DROP INDEX idx_name ON tbl_name;ALTER TABLE tbl_name DROP INDEX idx_name;

使用全文索引进行全模糊匹配的语法为:

SELECT XXX FROM tbl_name WHERE match(field_name) against('xxx');# 比如对 user_tbl 的 user_name 字段加了全文索引# 查询结果等效于 SELECT user_name, user_id FROM user_tbl WHERE user_name LIKE '%hello%';SELECT user_name, user_id FROM user_tbl WHERE match(user_name) against('hello');

使用 explain 检查,可以发现 fulltext 索引生效。
在这里插入图片描述

按物理实现划分

按物理实现方式来划分,通常可以分为聚集索引和非聚集索引。

聚集索引(clustered index)

存储内容是按照聚集索引排序的,聚集索引的顺序和行记录的顺序一致,一张表只能有一个聚集索引。聚集索引的叶子节点直接储存聚集索引指向的内容,因此查询的时候只需要进行一次查找。

聚集索引在创建主键时自动生成,如果没有主键,则根据第一个不为空的唯一索引自动生成,如果还没有,则自动生成一个隐式的聚集索引。

需要注意的是,在进行查询操作的时候,聚集索引的效率更高,因为少了一次查找;但是进行修改操作的时候,效率比非聚集索引低,因为直接修改了数据内容,为了标准数据内容的顺序和聚集索引顺序一致,会对数据页重新排序。

非聚集索引(non-clustered index)

非聚集索引虽然索引项是顺序存储的,但是索引项对应的内容是随机存储的,系统会维护单独的索引表来存储索引。

非聚集索引的叶子节点存储的是数据的地址,查询非聚集索引的时候,系统会进行两次查找,先查找索引,再查找索引对应位置的数据。因此非聚集索引也叫二级索引或者辅助索引。

按字段个数划分

按字段个数可以把索引分为单一索引和联合索引。

单一索引

索引字段只有一列时为单一索引,上述所有索引都是单一索引。

联合索引

将多个字段组合在一起创建的索引叫联合索引。如下:

纳米搜索 纳米搜索

纳米搜索:360推出的新一代AI搜索引擎

纳米搜索 30 查看详情 纳米搜索

ALTER TABLE user_tbl ADD INDEX idx_name_city_age (username,city,age);

最左匹配原则

建立这样的联合索引,其实是相当于分别建立了下面三组联合索引:

usernname,city,ageusernname,cityusernname

为什么没有 city,age 这样的联合索引呢?这是因为MySQL联合索引的最左匹配原则,只会按照最左优先的顺序进行索引匹配,也就是说,(x,y,z) 和 (z,y,x) 是不同的索引,即使是使用联合索引中的字段查询,联合索引也有可能失效。

对于 (x,y,z),只有在以下查询条件联合索引会生效:

WHERE x = 1WHERE x = 1 AND y = 1WHERE x = 1 AND y = 1 AND z = 1

对于其他情况,比如 WHERE y = 1WHERE y = 1 AND z = 1 等,就不会匹配联合索引,索引失效,注意对于 WHERE x = 1 AND z = 1,联合索引会对 x 生效,但是对 z 不生效。

可以扩展了解一下,理论上最左匹配原则中索引对 where 中子句的顺序也是敏感的,但是由于MySQL的查询优化器会自动调整 where 子句的条件顺序以使用适合的索引,所以实际上 where 子句顺序不影响索引的效果。

要注意的是,如果联合索引查询过程中有范围查询,就会停止匹配,比如下面的语句中, z 字段不能使用到索引:

WHERE x = 1 AND y > 2 AND z = 3

顺便提一下,可以用 explain 命令来查看在某个查询语句中索引是否生效,具体用法请参考官网文档。

如果分别在 x, y, z 上建立单列索引,让该表有3个单列索引,索引效率也会大不一样,在联合索引生效的情况下,单个索引的效率远远低于联合索引。这是由 MySQL 查询优化器的执行顺序决定的,在执行一条查询 sql 时,针对索引的选择大致有如下步骤:

MySQL 优化器根据搜索条件,找出所有可能使用的索引计算全表扫描的代价计算使用不同索引执行查询的代价对比各种执行方案的代价,找出成本最低的那一个

因此,虽然有多个单列索引,但 MySQL 只能用到其中的那个系统认为似乎是最有效率的,其他的就会失效。

按索引结构划分

不同的 mysql 数据引擎支持不同结构的索引,按结构划分,常用的索引为 B+树索引、Hash 索引、FULLTEXT索引 等,将在下一篇文章 MySQL 索引结构 中介绍。

使用总结

接下来我们来简单总结一下在什么场景下推荐使用索引。

推荐使用

WHERE, GROUP BY, ORDER BY 子句中的字段

多个单列索引在多条件查询是只会有一个最优的索引生效,因此多条件查询中最好创建联合索引。

联合索引的时候必须满足最左匹配原则,并且最好考虑到 sql 语句的执行顺序,比如 WHERE a = 1 GROUP BY b ORDER BY c, 那么联合索引应该设计为 (a,b,c),因为在上一篇文章 MySQL 基础语法 中我们介绍过,mysql 查询语句的执行顺序 WHERE > GROUP BY > ORDER BY。

多张表 JOIN 的时候,对表连接字段创建索引。

当 SELECT 中有不在索引中的字段时,会先通过索引查询出满足条件的主键值,然后通过主键回表查询出所有的 SELECT 中的字段,影响查询效率。因此如果 SELECT 中的内容很少,为了避免回表,可以把 SELECT 中的字段都加到联合索引中,这也就是宽索引的概念。但是需要注意,如果索引字段过多,存储和维护索引的成本也会增加。

不推荐使用或索引失效情况

数据量很小的表

有大量重复数据的字段

频繁更新的字段

如果对索引字段使用了函数或者表达式计算,索引失效

innodb OR 条件没有对所有条件创建索引,索引失效

大于小于条件 < >,索引是否生效取决于命中的数量比例,如果命中数量很多,索引生效,命中数量很小,索引失效

不等于条件 != ,索引失效

LIKE 值以 % 开头,索引失效

推荐学习:mysql视频教程

以上就是MySQL索引给拿捏住了的详细内容,更多请关注创想鸟其它相关文章!

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 chuangxiangniao@163.com 举报,一经查实,本站将立刻删除。
发布者:程序猿,转转请注明出处:https://www.chuangxiangniao.com/p/283625.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2025年11月4日 17:35:14
下一篇 2025年11月4日 17:36:16

相关推荐

  • 动态修改Knex查询中的表和连接模式

    本文探讨了在Knex QueryBuilder中动态管理和修改已添加的表和连接(JOIN)模式的挑战。由于Knex不直接提供访问或修改已构建查询内部结构的方法,文章提出了一种结合使用`queryBuilder.toString()`、字符串替换和`knex.raw()`的创新解决方案。通过在基础查询…

    2025年12月21日
    000
  • 前端Fetch POST与后端PHP $_POST的正确姿势

    本文详细阐述了在使用javascript fetch api发送application/x-www-form-urlencoded类型post请求时,php后端正确接收数据的方法。核心问题在于php脚本错误地尝试从url查询字符串中解析post数据,而非通过$_post超全局变量获取。教程将指导开发…

    2025年12月21日
    000
  • 前端日志收集系统_实现用户行为追踪与分析

    首先明确追踪目标,包括页面浏览、点击、表单、曝光、异常及自定义事件;接着通过自动采集与手动埋点结合的方式收集数据,使用统一日志结构包含时间戳、用户ID、页面路径等字段,并利用sendBeacon或fetch keepalive确保可靠上报;为优化性能,采用节流、批量发送、离线缓存与错误去重策略;后端…

    2025年12月21日
    000
  • 如何在Knex QueryBuilder中动态应用多数据库Schema

    本文探讨了在Knex QueryBuilder中动态管理和应用数据库schema的挑战,特别是当withSchema()方法无法覆盖所有联结(join)操作时。我们提出了一种通过SQL字符串占位符和knex.raw()进行替换的有效策略,从而实现灵活地将预定义查询应用于不同schema的需求,尤其适…

    2025年12月21日
    000
  • JavaScriptNode.js集成_JavaScript全栈开发

    JavaScript 全栈开发结合 Node.js 实现前后端统一语言,提升效率。1. 前后端共用 JavaScript,支持代码复用、降低学习成本、统一构建流程;2. Node.js 基于 V8 引擎,适配 I/O 密集型场景,配合 Express.js、Koa 或 NestJS 框架快速搭建后端…

    2025年12月21日
    000
  • 服务端API_javascript后端开发

    使用JavaScript进行服务端API开发主要依赖Node.%ignore_a_1%,它基于V8引擎实现服务器端运行,适合I/O密集型场景。选择JavaScript的核心原因在于其全栈统一能力,前后端可共用语言,降低开发成本。Node.js具备非阻塞I/O、事件驱动架构,支持高并发,配合npm生态…

    2025年12月21日
    000
  • Knex QueryBuilder:动态为现有查询添加Schema的策略

    本文探讨了在knex querybuilder中动态为已构建查询(包括from子句和join子句中的表)添加或修改数据库schema的策略。由于knex不直接提供api来检索和修改已添加的join信息,我们介绍了一种利用sql字符串替换的变通方法。该方法通过在初始查询中使用占位符,然后将其转换为sq…

    2025年12月21日 好文分享
    000
  • JavaScript数据库操作_JavaScript数据持久化方案

    JavaScript无内置数据库,但可通过多种方案实现数据持久化:浏览器端可用localStorage、sessionStorage、IndexedDB及Cache API;Node.js服务端可连接MySQL、PostgreSQL、MongoDB或SQLite;跨平台方案包括LevelDB、Fir…

    2025年12月21日
    000
  • javascript_数据库操作优化

    使用连接池复用数据库连接,减少开销;2. 批量操作替代单条执行,提升I/O效率;3. 为查询字段添加索引,优化SQL语句;4. 引入Redis等缓存热点数据,降低数据库负载;5. IndexedDB中合并事务、建立索引并使用游标遍历,提升前端存储性能。 JavaScript 中的数据库操作优化主要取…

    2025年12月21日
    000
  • Node.js后端开发_javascript全栈技术

    Node.js结合JavaScript全栈开发,实现前后端统一语言,提升效率。1. Node.js基于V8引擎,事件驱动、非阻塞I/O,适合高并发实时应用;2. 技术栈涵盖前端React/Vue、后端Express/Koa、数据库Mongoose/Sequelize、通信Axios+JWT、实时So…

    2025年12月21日
    000
  • JavaScript数据库_javascript数据存储

    浏览器中JavaScript可通过localStorage持久存字符串、sessionStorage临时存数据、IndexedDB存储大量结构化数据、Cache API缓存网络请求;2. Node.js环境可用fs模块读写JSON文件、SQLite轻量数据库或连接MongoDB/MySQL/Post…

    2025年12月21日
    000
  • PHP与JavaScript Fetch POST请求数据交互指南

    本教程旨在解决php脚本无法正确接收javascript fetch api发送的post请求数据的问题。核心在于理解post数据通过请求体而非url查询字符串传输,并指导php如何正确使用$_post超全局变量来获取这些数据,同时强调数据安全与最佳实践。 在现代Web开发中,客户端(通常是浏览器中…

    2025年12月21日
    000
  • JavaScript数据库操作_ORM与原生查询性能对比

    ORM开发效率高但性能较低,原生SQL性能优但开发成本高。1. ORM适合快速开发、团队水平不均、需类型安全与迁移管理的场景;2. 原生查询适用于高频核心接口、复杂报表、大数据量及对延迟敏感的服务。 在现代Web开发中,数据库操作是核心环节之一。JavaScript(尤其是Node.js)生态中,开…

    2025年12月21日
    000
  • RESTfulAPI怎么用Node.js开发_RESTfulAPI设计与Node.js实现全流程

    答案:使用Node.js开发RESTful API需遵循REST规范,通过Express框架搭建服务,定义路由实现增删改查,返回标准状态码与JSON数据,并通过模块化、验证、数据库连接和错误处理提升质量。 用Node.js开发RESTful API,核心是搭建HTTP服务并定义符合REST规范的接口…

    2025年12月21日
    000
  • AJAX 返回数据中 JSON 字符串嵌套解析的常见陷阱与解决方案

    在处理 ajax 请求返回的数据时,如果数据库中(如 mysql 的 `longtext` 字段)存储的是 json 字符串,并作为另一个 json 对象的属性返回,前端直接访问其内部属性会得到 `undefined`。这是因为该嵌套的 json 字符串并未被自动解析。本文将深入探讨这一问题,并提供…

    2025年12月21日
    000
  • AJAX数据处理:正确解析嵌套JSON字符串以访问内部属性

    在ajax请求中,当从后端接收到的数据字段(如从数据库`longtext`列读取的json字符串)本身是一个未解析的json字符串时,直接访问其内部属性会导致`undefined`。本文将深入探讨此问题,并提供通过二次`json.parse()`解析来正确访问嵌套json数据属性的专业解决方案,确保…

    2025年12月21日
    000
  • AJAX数据中嵌套JSON字符串的解析与处理:避免属性访问undefined

    在进行ajax数据交互时,常见的问题是后端返回的数据中,某个字段(尤其当其来源于数据库的`longtext`类型)看似是json对象,但实际仍是一个未解析的json字符串。直接尝试访问其内部属性会导致`undefined`错误。解决此问题的关键在于对该嵌套的json字符串进行二次`json.pars…

    2025年12月21日
    000
  • AJAX数据解析:解决JSON中嵌套JSON字符串的访问问题

    本文探讨了ajax请求返回的json数据中,某个字段值实际上是另一个json结构字符串的常见问题。文章解释了为何直接访问此类嵌套属性会导致`undefined`,并提供了明确的解决方案:通过`json.parse()`方法对嵌套的json字符串进行二次解析,将其转换为可操作的javascript对象…

    2025年12月21日
    000
  • JavaScript中解析嵌套JSON字符串:避免undefined错误

    本文旨在解决ajax响应中json数据解析的常见问题,特别是当json字段的值本身是一个被引号包裹的json字符串时,导致尝试访问内部属性时出现`undefined`。文章将详细解释问题根源,并提供使用`json.parse()`进行二次解析的解决方案,同时探讨相关的最佳实践和注意事项,帮助开发者更…

    2025年12月21日
    000
  • JavaScript数据库操作与ORM

    JavaScript在Node.js中通过库操作数据库,常用方式包括原生驱动、查询构建器和ORM。ORM如Sequelize、TypeORM和Mongoose将数据表映射为对象,提升开发效率,支持安全查询与迁移管理,但可能存在性能损耗与学习成本,需结合项目需求选择工具。 JavaScript 本身并…

    2025年12月21日
    000

发表回复

登录后才能评论
关注微信