技术博客 技术博客
  • JAVA
  • 仓颉
  • 设计模式
  • 人工智能
  • Spring
  • Mybatis
  • Maven
  • Git
  • Kafka
  • RabbitMQ
  • RocketMQ
  • Redis
  • Zookeeper
  • Nginx
  • 数据库套件
  • MySQL
  • Elasticsearch
  • MongoDB
  • Hadoop
  • ClickHouse
  • Hbase
  • Hive
  • Flink
  • Flume
  • SQLite
  • linux
  • Docker
  • Jenkins
  • Kubernetes
  • 工具
  • 前端
  • AI
GitHub (opens new window)
  • JAVA
  • 仓颉
  • 设计模式
  • 人工智能
  • Spring
  • Mybatis
  • Maven
  • Git
  • Kafka
  • RabbitMQ
  • RocketMQ
  • Redis
  • Zookeeper
  • Nginx
  • 数据库套件
  • MySQL
  • Elasticsearch
  • MongoDB
  • Hadoop
  • ClickHouse
  • Hbase
  • Hive
  • Flink
  • Flume
  • SQLite
  • linux
  • Docker
  • Jenkins
  • Kubernetes
  • 工具
  • 前端
  • AI
GitHub (opens new window)
  • mysql

    • MySQL 问题汇总
    • MySQL 索引介绍
      • MySQL中索引的语法
        • 创建索引
        • 注意:
        • 根据索引查询
        • 删除索引
        • 查看表中的索引
        • 查看查询语句使用索引的情况
      • 索引的优缺点
      • 索引的分类
        • 常见的索引类型有:主键索引、唯一索引、普通索引、全文索引、组合索引
      • 索引的实现原理
        • 哈希索引:
        • 全文索引:
        • 注意:
        • BTree索引和B+Tree索引
      • 索引的使用策略
        • 什么时候要使用索引?
        • 什么时候不要使用索引?
        • 索引失效的情况:
      • 索引的优化
    • MySQL 锁介绍
    • MySQL 索引优化工具 explain
    • MySQL 主从复制(GTID)
    • MySQL 8安装
    • MySQL 8.x新特性总结
    • MySQL UDF以及新类型JSON
    • MySQL 高可用MGR(一) 理论
    • MySQL 高可用MGR(二) 搭建
    • MySQL 高可用MGR(三) 测试
  • Elasticsearch

    • ES 7.8.0(一) 入门介绍
    • ES 7.8.0(二) 读、写和写索引流程以及文档分析过程
    • ES 7.8.0(三) 文档冲突
  • mongodb

    • mongodb
  • hadoop

    • Hadoop 伪分布式及集群
    • Hadoop 指令
    • Hadoop 读写流程详解
    • Hadoop SpringBoot集成
    • Hadoop MapReduce机制
    • Hadoop YARN
    • Hadoop MapReduce配置和编写job及数据倾斜的解决
    • Hadoop MapReduce自定义格式输入输出
  • clickhouse

    • ClickHouse 介绍及安装
    • ClickHouse 数据类型
    • ClickHouse 表引擎
    • ClickHouse SQL操作
    • ClickHouse 副本配置
    • ClickHouse 分片与集群部署
    • ClickHouse Explain及建表优化
    • ClickHouse 语法优化规则
    • ClickHouse 查询优化
    • ClickHouse 数据一致性
    • ClickHouse 物化视图
    • ClickHouse MaterializeMySQL引擎
    • ClickHouse 监控及备份
  • hbase

    • Hbase 介绍及安装
    • Hbase 优化
    • Hbase phoenix安装及使用
    • Hbase LSM-TREE
  • hive

    • Hive 介绍及安装
    • Hive 内外部表、分区表、分桶表概念及hiveSQL命令
    • Hive 数据类型
    • Hive 函数 MySQL联合
    • Hive 数据倾斜和优化
    • Hive Sqoop安装及指令
  • flink

    • Flink 介绍及安装
    • Flink 配置介绍及Demo
    • Flink API讲解
    • Flink 运行架构
    • Flink 时间语义及Watermark
    • Flink 状态管理
    • Flink 容错,检查点,保存点
    • Flink 状态一致性
    • Flink Table API 和 Flink SQL
    • Flink CEP编程
    • Flink Joining编程
    • Flink CDC
  • flume

    • Flume 日志收集系统介绍及安装
    • Flume Source支持的类型
    • Flume Sink支持的类型
    • Flume Channel支持的类型
    • Flume Selector
    • Flume Interceptor拦截器类型
    • Flume Process
  • sqlite

    • SQLite介绍
目录

MySQL 索引介绍

# MySQL 中索引的语法

# 创建索引

在创建表的时候添加索引

CREATE TABLE mytable(  
    ID INT NOT NULL,   
    username VARCHAR(16) NOT NULL,  
    INDEX [indexName] (username(length))  
); 
1
2
3
4
5

在创建表以后添加索引

ALTER TABLE my_table ADD [UNIQUE] INDEX index_name(column_name);
# 或者
CREATE INDEX index_name ON my_table(column_name);
1
2
3

# 注意:

  1. 索引需要占用磁盘空间,因此在创建索引时要考虑到磁盘空间是否足够
  2. 创建索引时需要对表加锁,因此实际操作中需要在业务空闲期间进行

# 根据索引查询

--具体查询:
SELECT * FROM table_name WHERE column_1=column_2;(为column_1建立了索引)

--或者模糊查询
SELECT * FROM table_name WHERE column_1 LIKE '%三'
SELECT * FROM table_name WHERE column_1 LIKE '三%'
SELECT * FROM table_name WHERE column_1 LIKE '%三%'

SELECT * FROM table_name WHERE column_1 LIKE '_好_'

--如果要表示在字符串中既有A又有B,那么查询语句为:
SELECT * FROM table_name WHERE column_1 LIKE '%A%' AND column_1 LIKE '%B%';

SELECT * FROM table_name WHERE column_1 LIKE '[张李王]三';  --表示column_1中有匹配张三、李三、王三的都可以
SELECT * FROM table_name WHERE column_1 LIKE '[^张李王]三';  --表示column_1中有匹配除了张三、李三、王三的其他三都可以

-- 在模糊查询中,%表示任意0个或多个字符;_表示任意单个字符(有且仅有),通常用来限制字符串长度;[]表示其中的某一个字符;[^]表示除了其中的字符的所有字符

--或者在全文索引中模糊查询
SELECT * FROM table_name WHERE MATCH(content) AGAINST('word1','word2',...);
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

# 删除索引

DROP INDEX my_index ON tablename;
--或者
ALTER TABLE table_name DROP INDEX index_name;
1
2
3

# 查看表中的索引

SHOW INDEX FROM tablename
1

# 查看查询语句使用索引的情况

-- explain 查询语句
explain SELECT * FROM table_name WHERE column_1='123';
1
2

# 索引的优缺点

优势:可以快速检索,减少 I/O 次数,加快检索速度;根据索引分组和排序,可以加快分组和排序;

劣势:索引本身也是表,因此会占用存储空间,一般来说,索引表占用的空间的数据表的 1.5 倍;索引表的维护和创建需要时间成本,这个成本随着数据量增大而增大;构建索引会降低数据表的修改操作(删除,添加,修改)的效率,因为在修改数据表的同时还需要修改索引表;

# 索引的分类

# 常见的索引类型有:主键索引、唯一索引、普通索引、全文索引、组合索引

1、主键索引:即主索引,根据主键 pk_clolum(length)建立索引,不允许重复,不允许空值;

ALTER TABLE 'table_name' ADD PRIMARY KEY pk_index('col');
1

2、唯一索引:用来建立索引的列的值必须是唯一的,允许空值

ALTER TABLE 'table_name' ADD UNIQUE index_name('col');
1

3、普通索引:用表中的普通列构建的索引,没有任何限制

ALTER TABLE 'table_name' ADD INDEX index_name('col');
1

4、全文索引:用大文本对象的列构建的索引(下一部分会讲解)

ALTER TABLE 'table_name' ADD FULLTEXT INDEX ft_index('col');
1

5、组合索引:用多个列组合构建的索引,这多个列中的值不允许有空值

ALTER TABLE 'table_name' ADD INDEX index_name('col1','col2','col3');
1
  • 遵循 “最左前缀” 原则,把最常用作为检索或排序的列放在最左,依次递减,组合索引相当于建立了 col1,col1col2,col1col2col3 三个索引,而 col2 或者 col3 是不能使用索引的。
  • 在使用组合索引的时候可能因为列名长度过长而导致索引的 key 太大,导致效率降低,在允许的情况下,可以只取 col1 和 col2 的前几个字符作为索引
  • ALTER TABLE 'table_name' ADD INDEX index_name(col1(4),col2(3));
    表示使用 col1 的前 4 个字符和 col2 的前 3 个字符作为索引

# 索引的实现原理

MySQL 支持诸多存储引擎,而各种存储引擎对索引的支持也各不相同,因此 MySQL 数据库支持多种索引类型,如 BTree 索引,B+Tree 索引,哈希索引,全文索引等等,

# 哈希索引:

只有 memory(内存)存储引擎支持哈希索引,哈希索引用索引列的值计算该值的 hashCode,然后在 hashCode 相应的位置存执该值所在行数据的物理位置,因为使用散列算法,因此访问速度非常快,但是一个值只能对应一个 hashCode,而且是散列的分布方式,因此哈希索引不支持范围查找和排序的功能。

# 全文索引:

FULLTEXT(全文)索引,仅可用于 MyISAM 和 InnoDB,针对较大的数据,生成全文索引非常的消耗时间和空间。对于文本的大对象,或者较大的 CHAR 类型的数据,如果使用普通索引,那么匹配文本前几个字符还是可行的,但是想要匹配文本中间的几个单词,那么就要使用 LIKE % word% 来匹配,这样需要很长的时间来处理,响应时间会大大增加,这种情况,就可使用时 FULLTEXT 索引了,在生成 FULLTEXT 索引时,会为文本生成一份单词的清单,在索引时及根据这个单词的清单来索引。FULLTEXT 可以在创建表的时候创建,也可以在需要的时候用 ALTER 或者 CREATE INDEX 来添加:

--创建表的时候添加FULLTEXT索引
CTREATE TABLE my_table(
    id INT(10) PRIMARY KEY,
    name VARCHAR(10) NOT NULL,
    my_text TEXT,
    FULLTEXT(my_text)
)ENGINE=MyISAM DEFAULT CHARSET=utf8;
1
2
3
4
5
6
7
--创建表以后,在需要的时候添加FULLTEXT索引
ALTER TABLE my_table ADD FULLTEXT INDEX ft_index(column_name);
1
2

全文索引的查询也有自己特殊的语法,而不能使用 LIKE % 查询字符串 % 的模糊查询语法

SELECT * FROM table_name MATCH(ft_index) AGAINST('查询字符串');
1

# 注意:

  • 对于较大的数据集,把数据添加到一个没有 FULLTEXT 索引的表,然后添加 FULLTEXT 索引的速度比把数据添加到一个已经有 FULLTEXT 索引的表快。

  • 5.6 版本前的 MySQL 自带的全文索引只能用于 MyISAM 存储引擎,如果是其它数据引擎,那么全文索引不会生效。5.6 版本之后 InnoDB 存储引擎开始支持全文索引

  • 在 MySQL 中,全文索引支队英文有用,目前对中文还不支持。5.7 版本之后通过使用 ngram 插件开始支持中文。

  • 在 MySQL 中,如果检索的字符串太短则无法检索得到预期的结果,检索的字符串长度至少为 4 字节,此外,如果检索的字符包括停止词,那么停止词会被忽略。

# BTree 索引和 B+Tree 索引

1、BTree 索引
BTree 是平衡搜索多叉树,设树的度为 2d(d>1),高度为 h,那么 BTree 要满足以一下条件:

  • 每个叶子结点的高度一样,等于 h;
  • 每个非叶子结点由 n-1 个 key 和 n 个指针 point 组成,其中 d<=n<=2d,key 和 point 相互间隔,结点两端一定是 key;
  • 叶子结点指针都为 null;
  • 非叶子结点的 key 都是 [key,data] 二元组,其中 key 表示作为索引的键,data 为键值所在行的数据;
    结构如下:

在 BTree 的机构下,就可以使用二分查找的查找方式,查找复杂度为 h*log (n),一般来说树的高度是很小的,一般为 3 左右,因此 BTree 是一个非常高效的查找结构。

2、B+Tree 索引
B+Tree 是 BTree 的一个变种,设 d 为树的度数,h 为树的高度,B+Tree 和 BTree 的不同主要在于:

  • B+Tree 中的非叶子结点不存储数据,只存储键值;
  • B+Tree 的叶子结点没有指针,所有键值都会出现在叶子结点上,且 key 存储的键值对应 data 数据的物理地址;
  • B+Tree 的每个非叶子节点由 n 个键值 key 和 n 个指针 point 组成;
    B+Tree 的结构如下:

B+Tree 对比 BTree 的优点:

  • 磁盘读写代价更低
    一般来说 B+Tree 比 BTree 更适合实现外存的索引结构,因为存储引擎的设计专家巧妙的利用了外存(磁盘)的存储结构,即磁盘的最小存储单位是扇区(sector),而操作系统的块(block)通常是整数倍的 sector,操作系统以页(page)为单位管理内存,一页(page)通常默认为 4K,数据库的页通常设置为操作系统页的整数倍,因此索引结构的节点被设计为一个页的大小,然后利用外存的 “预读取” 原则,每次读取的时候,把整个节点的数据读取到内存中,然后在内存中查找,已知内存的读取速度是外存读取 I/O 速度的几百倍,那么提升查找速度的关键就在于尽可能少的磁盘 I/O,那么可以知道,每个节点中的 key 个数越多,那么树的高度越小,需要 I/O 的次数越少,因此一般来说 B+Tree 比 BTree 更快,因为 B+Tree 的非叶节点中不存储 data,就可以存储更多的 key。

  • 查询速度更稳定
    由于 B+Tree 非叶子节点不存储数据(data),因此所有的数据都要查询至叶子节点,而叶子节点的高度都是相同的,因此所有数据的查询速度都是一样的。
    更多操作系统内容参考:
    硬盘结构
    扇区、块、簇、页的区别
    操作系统层优化(进阶,初学不用看)

带顺序索引的 B+TREE:
很多存储引擎在 B+Tree 的基础上进行了优化,添加了指向相邻叶节点的指针,形成了带有顺序访问指针的 B+Tree,这样做是为了提高区间查找的效率,只要找到第一个值那么就可以顺序的查找后面的值
B+Tree 的结构如下:

3、聚簇索引和非聚簇索引
分析了 MySQL 的索引结构的实现原理,然后我们来看看具体的存储引擎怎么实现索引结构的,MySQL 中最常见的两种存储引擎分别是 MyISAM 和 InnoDB,分别实现了非聚簇索引和聚簇索引。

聚簇索引的解释是:聚簇索引的顺序就是数据的物理存储顺序

非聚簇索引的解释是:索引顺序与数据物理排列顺序无关

(这样说起来并不好理解,让人摸不着头脑,清继续看下文,并在插图下方对上述两句话有解释)

首先要介绍几个概念,在索引的分类中,我们可以按照索引的键是否为主键来分为 “主索引” 和 “辅助索引”,使用主键键值建立的索引称为 “主索引”,其它的称为 “辅助索引”。因此主索引只能有一个,辅助索引可以有很多个。

4、MyISAM—— 非聚簇索引

  • MyISAM 存储引擎采用的是非聚簇索引,非聚簇索引的主索引和辅助索引几乎是一样的,只是主索引不允许重复,不允许空值,他们的叶子结点的 key 都存储指向键值对应的数据的物理地址。
  • 非聚簇索引的数据表和索引表是分开存储的。
  • 非聚簇索引中的数据是根据数据的插入顺序保存。因此非聚簇索引更适合单个数据的查询。插入顺序不受键值影响。
  • 只有在 MyISAM 中才能使用 FULLTEXT 索引。(mysql5.6 以后 innoDB 也支持全文索引)

最开始我一直不懂既然非聚簇索引的主索引和辅助索引指向相同的内容,为什么还要辅助索引这个东西呢,后来才明白索引不就是用来查询的吗,用在那些地方呢,不就是 WHERE 和 ORDER BY 语句后面吗,那么如果查询的条件不是主键怎么办呢,这个时候就需要辅助索引了。

5、InnoDB—— 聚簇索引

  • 聚簇索引的主索引的叶子结点存储的是键值对应的数据本身,辅助索引的叶子结点存储的是键值对应的数据的主键键值。因此主键的值长度越小越好,类型越简单越好。
  • 聚簇索引的数据和主键索引存储在一起。
  • 聚簇索引的数据是根据主键的顺序保存。因此适合按主键索引的区间查找,可以有更少的磁盘 I/O,加快查询速度。但是也是因为这个原因,聚簇索引的插入顺序最好按照主键单调的顺序插入,否则会频繁的引起页分裂,严重影响性能。
  • 在 InnoDB 中,如果只需要查找索引的列,就尽量不要加入其它的列,这样会提高查询效率。
    使用主索引的时候,更适合使用聚簇索引,因为聚簇索引只需要查找一次,而非聚簇索引在查到数据的地址后,还要进行一次 I/O 查找数据。

因为聚簇辅助索引存储的是主键的键值,因此可以在数据行移动或者页分裂的时候降低成本,因为这时不用维护辅助索引。但是由于主索引存储的是数据本身,因此聚簇索引会占用更多的空间。

聚簇索引在插入新数据的时候比非聚簇索引慢很多,因为插入新数据时需要检测主键是否重复,这需要遍历主索引的所有叶节点,而非聚簇索引的叶节点保存的是数据地址,占用空间少,因此分布集中,查询的时候 I/O 更少,但聚簇索引的主索引中存储的是数据本身,数据占用空间大,分布范围更大,可能占用好多的扇区,因此需要更多次 I/O 才能遍历完毕。

下图可以形象的说明聚簇索引和非聚簇索引的区别:

从上图中可以看到聚簇索引的辅助索引的叶子节点的 data 存储的是主键的值,主索引的叶子节点的 data 存储的是数据本身,也就是说数据和索引存储在一起,并且索引查询到的地方就是数据(data)本身,那么索引的顺序和数据本身的顺序就是相同的;

而非聚簇索引的主索引和辅助索引的叶子节点的 data 都是存储的数据的物理地址,也就是说索引和数据并不是存储在一起的,数据的顺序和索引的顺序并没有任何关系,也就是索引顺序与数据物理排列顺序无关。

此外 MyISAM 和 innoDB 的区别总结如下:

6、总结

  • InnoDB 支持事务,支持行级别锁定,支持 B-tree、Full-text 等索引,不支持 Hash 索引;
  • MyISAM 不支持事务,支持表级别锁定,支持 B-tree、Full-text 等索引,不支持 Hash 索引;
    此外,Memory 不支持事务,支持表级别锁定,支持 B-tree、Hash 等索引,不支持 Full-text 索引;

# 索引的使用策略

# 什么时候要使用索引?

  • 主键自动建立唯一索引;
  • 经常作为查询条件在 WHERE 或者 ORDER BY 语句中出现的列要建立索引;
  • 作为排序的列要建立索引;
  • 查询中与其他表关联的字段,外键关系建立索引
  • 高并发条件下倾向组合索引;
  • 用于聚合函数的列可以建立索引,例如使用了 max (column_1) 或者 count (column_1) 时的 column_1 就需要建立索引

# 什么时候不要使用索引?

  • 经常增删改的列不要建立索引;
  • 有大量重复的列不建立索引;
  • 表记录太少不要建立索引。只有当数据库里已经有了足够多的测试数据时,它的性能测试结果才有实际参考价值。如果在测试数据库里只有几百条数据记录,它们往往在执行完第一条查询命令之后就被全部加载到内存里,这将使后续的查询命令都执行得非常快 -- 不管有没有使用索引。只有当数据库里的记录超过了 1000 条、数据总量也超过了 MySQL 服务器上的内存总量时,数据库的性能测试结果才有意义。

# 索引失效的情况:

  • 在组合索引中不能有列的值为 NULL,如果有,那么这一列对组合索引就是无效的。

  • 在一个 SELECT 语句中,索引只能使用一次,如果在 WHERE 中使用了,那么在 ORDER BY 中就不要用了。

  • LIKE 操作中,'% aaa%' 不会使用索引,也就是索引会失效,但是‘aaa%’可以使用索引。

  • 在索引的列上使用表达式或者函数会使索引失效,例如:select * from users where YEAR (adddate)<2007,将在每个行上进行运算,这将导致索引失效而进行全表扫描,因此我们可以改成:select * from users where adddate<’2007-01-01′。其它通配符同样,也就是说,在查询条件中使用正则表达式时,只有在搜索模板的第一个字符不是通配符的情况下才能使用索引。

  • 在查询条件中使用不等于,包括 <符号、> 符号和!= 会导致索引失效。特别的是如果对主键索引使用!= 则不会使索引失效,如果对主键索引或者整数类型的索引使用 < 符号或者 > 符号不会使索引失效。(经 erwkjrfhjwkdb 同学提醒,不等于,包括 < 符号、> 符号和!,如果占总记录的比例很小的话,也不会失效)

  • 在查询条件中使用 IS NULL 或者 IS NOT NULL 会导致索引失效。

  • 字符串不加单引号会导致索引失效。更准确的说是类型不一致会导致失效,比如字段 email 是字符串类型的,使用 WHERE email=99999 则会导致失败,应该改为 WHERE email='99999'。

  • 在查询条件中使用 OR 连接多个条件会导致索引失效,除非 OR 链接的每个条件都加上索引,这时应该改为两次查询,然后用 UNION ALL 连接起来。

  • 如果排序的字段使用了索引,那么 select 的字段也要是索引字段,否则索引失效。特别的是如果排序的是主键索引则 select * 也不会导致索引失效。

  • 尽量不要包括多列排序,如果一定要,最好为这队列构建组合索引;

# 索引的优化

1、最左前缀

索引的最左前缀和和 B+Tree 中的 “最左前缀原理” 有关,举例来说就是如果设置了组合索引 < col1,col2,col3 > 那么以下 3 中情况可以使用索引:col1,<col1,col2>,<col1,col2,col3>,其它的列,比如 < col2,col3>,<col1,col3>,col2,col3 等等都是不能使用索引的。

根据最左前缀原则,我们一般把排序分组频率最高的列放在最左边,以此类推。

2、带索引的模糊查询优化

在上面已经提到,使用 LIKE 进行模糊查询的时候,'% aaa%' 不会使用索引,也就是索引会失效。如果是这种情况,只能使用全文索引来进行优化(上文有讲到)。

3、为检索的条件构建全文索引,然后使用

SELECT * FROM tablename MATCH(index_colum) ANGAINST('word');
1

4、使用短索引

对串列进行索引,如果可能应该指定一个前缀长度。例如,如果有一个 CHAR (255) 的 列,如果在前 10 个或 20 个字符内,多数值是惟一的,那么就不要对整个列进行索引。短索引不仅可以提高查询速度而且可以节省磁盘空间和 I/O 操作。

上次更新: 6/11/2025, 4:10:30 PM
MySQL 问题汇总
MySQL 锁介绍

← MySQL 问题汇总 MySQL 锁介绍→

Theme by Vdoing | Copyright © 2023-2025
  • 跟随系统
  • 浅色模式
  • 深色模式
  • 阅读模式