MySQL8.0新特性——不可见索引(Invisible Indexes)

MySQL8.0开始支持看不见的索引。一个看不见的索引根本不被优化器使用,但是通常是保持正常的。默认情况下索引是可见的。不可见的索引使测试在查询性能上删除索引的效果成为可能,而不需要在需要索引的情况下进行破坏性的更改。

注意:

该特性适用于除主键以外的索引(显式或隐式)默认情况下索引是可见的!。

将index设置为invisible,会导致优化器在选择执行计划时,自动忽略该索引,即便使用了FORCE INDEX

官方文档:

https://dev.mysql.com/doc/refman/8.0/en/invisible-indexes.html

1、创建测试表t1,并创建3个不可见索引

mysql> CREATE TABLE t1 (i INT,j INT,k INT, INDEX i_idx (i) INVISIBLE) ENGINE = InnoDB;
mysql> CREATE INDEX j_idx ON t1 (j) INVISIBLE;   --创建不可见索引:j_idx
mysql> ALTER TABLE t1 ADD INDEX k_idx (k) INVISIBLE;  --创建不可见索引:k_idx
mysql> SELECT INDEX_NAME, IS_VISIBLE   FROM INFORMATION_SCHEMA.STATISTICS   WHERE TABLE_SCHEMA = 'test' AND TABLE_NAME = 't1';   --可以看到3个索引都是不可见状态
+------------+------------+
| INDEX_NAME | IS_VISIBLE |
+------------+------------+
| i_idx      | NO         |
| j_idx      | NO         |
| k_idx      | NO         |
+------------+------------+
3 rows in set (0.00 sec)

2、修改索引为可见状态,也就是可使用的状态

mysql> ALTER TABLE t1 ALTER INDEX i_idx VISIBLE;   --修改索引为可见状态
mysql> SELECT INDEX_NAME, IS_VISIBLE   FROM INFORMATION_SCHEMA.STATISTICS   WHERE TABLE_SCHEMA = 'test' AND TABLE_NAME = 't1';  --可以看到状态为yes了。
+------------+------------+
| INDEX_NAME | IS_VISIBLE |
+------------+------------+
| i_idx      | YES        |
| j_idx      | NO         |
| k_idx      | NO         |
+------------+------------+
3 rows in set (0.00 sec)

注意:

主键索引是不能被设为不可见索引的!!!!!

一个没有显式主键的表可能仍然有一个有效的隐式主键,如果它在非空列上有任何惟一的索引。在这种情况下,第一个这样的索引将同样的约束放在表中行上,作为一个显式的主键,而该索引不能被忽略。如下:

3、创建测试表:t2,并设置唯一索引:j_idx(这个表没有明确主键,但是在NOT NULL列j上的索引在行上放置了相同的约束,可以作为主键)

mysql> CREATE TABLE t2 (i INT NOT NULL,j INT NOT NULL,UNIQUE j_idx (j)) ENGINE = InnoDB;  
Query OK, 0 rows affected (0.12 sec)
mysql> SELECT INDEX_NAME, IS_VISIBLE   FROM INFORMATION_SCHEMA.STATISTICS   WHERE TABLE_SCHEMA = 'test' AND TABLE_NAME = 't2';
+------------+------------+
| INDEX_NAME | IS_VISIBLE |
+------------+------------+
| j_idx      | YES        |
+------------+------------+
1 row in set (0.00 sec)

3.1、将索引设置为不可见索引:会发现报错

mysql> ALTER TABLE t2 ALTER INDEX j_idx INVISIBLE;

ERROR 3522 (HY000): A primary key index cannot be invisible

(报错是因为:虽然这个表没有明确的主键,但是在NOT NULL列j上的索引在行上放置了相同的约束,作为主键,不能被忽略:)

3.2、增加一个主键,如下:

mysql> ALTER TABLE t2 ADD PRIMARY KEY (i);   --增加一个主键
mysql> SELECT INDEX_NAME, IS_VISIBLE   FROM INFORMATION_SCHEMA.STATISTICS   WHERE TABLE_SCHEMA = 'test' AND TABLE_NAME = 't2';   --可以查看到有一个主键索引
+------------+------------+
| INDEX_NAME | IS_VISIBLE |
+------------+------------+
| j_idx      | YES        |
| PRIMARY    | YES        |
+------------+------------+
2 rows in set (0.00 sec)

3.3、这时候,将j_idx索引设置为不可见状态是可以的,如:

mysql> ALTER TABLE t2 ALTER INDEX j_idx INVISIBLE;
mysql> SELECT INDEX_NAME, IS_VISIBLE   FROM INFORMATION_SCHEMA.STATISTICS   WHERE TABLE_SCHEMA = 'test' AND TABLE_NAME = 't2';
+------------+------------+
| INDEX_NAME | IS_VISIBLE |
+------------+------------+
| j_idx      | NO         |
| PRIMARY    | YES        |
+------------+------------+
2 rows in set (0.00 sec)

从上面可以看出,已经存了显示的主机,而j_idx唯一索引不再充当隐式主键,因此可以将其设置为不可见状态。

4、日常操作:

--创建表指定索引为不可见状态:

create table t1(id int primary key,name varchar(10),index idx_name (name) invisible);

--修改索引为可见状态:

alter table t1 alter index idx_name visible;

--修改索引为不可见状态:

alter table t1 alter index idx_name invisible;

--查看数据库中有哪些不可见索引:

mysql> select table_schema,table_name,index_name,column_name,is_visible from information_schema.statistics where is_visible='no';

原文地址:http://blog.51cto.com/fengfeng688/2143982

时间: 2024-10-29 11:37:05

MySQL8.0新特性——不可见索引(Invisible Indexes)的相关文章

MySQL8.0新特性【转】

Server层,选项持久化 mysql> show variables like '%max_connections%'; +------------------------+-------+ | Variable_name | Value | +------------------------+-------+ | max_connections | 512 | | mysqlx_max_connections | 100 | +------------------------+-------

MySQL8.0 新特性:Partial Update of LOB Column

摘要: MySQL8.0对json进行了比较完善的支持, 我们知道json具有比较特殊的存储格式,通常存在多个key value键值对,对于类似更新操作通常不会更新整个json列,而是某些键值. 对于某些复杂的应用,json列的数据可能会变的非常庞大,这时候一个突出的问题是:innodb并不识别json类型,对它而言这些存储统一都是LOB类型,而在之前的版本中Innodb处理LOB更新的方式是标记删除旧记录,并插入新记录,显然这会带来一些存储上的开销(尽管Purge线程会去后台清理),而写入的r

深入解读MySQL8.0 新特性 :Crash Safe DDL

前言在MySQL8.0之前的版本中,由于架构的原因,mysql在server层使用统一的frm文件来存储表元数据信息,这个信息能够被不同的存储引擎识别.而实际上innodb本身也存储有元数据信息.这给ddl带来了一定的挑战,因为这种架构无法做到ddl的原子化,我们在线上经常能够看到数据目录下遗留的临时文件,或者类似server层和innodb层列个数不一致之类的错误.甚至某些ddl可能还遗留元数据在innodb内,而丢失了frm,导致无法重建表-..(我们为了解决这个问题,实现了一个叫drop

MySQL8.0新特性

MySQL从5.7一跃直接到8.0,这其中的缘由,咱就不关心那么多了,有兴趣的朋友自行百度,本次的版本更新,在功能上主要有以下6点: 账户与安全 优化器索引 通用表表达式 窗口函数 InnoDB 增强 JSON 增强 一.账户与安全 1.用户的创建与授权 在MySQL5.7的版本: > grant all privileges on *.* to '用户名'@'主机' identified by '密码': 在MySQL8.0需要分开执行: >create user '用户名'@'主机' id

MySQL8.0 新特性 Hash Join

概述&背景 MySQL一直被人诟病没有实现HashJoin,最新发布的8.0.18已经带上了这个功能,令人欣喜.有时候在想,MySQL为什么一直不支持HashJoin呢?我想可能是因为MySQL多用于简单的OLTP场景,并且在互联网应用居多,需求没那么紧急.另一方面可能是因为以前完全靠社区,这种演进速度毕竟有限,Oracle收购MySQL后,MySQL的发版演进速度明显加快了很多. HashJoin本身算法实现并不复杂,要说复杂,可能是优化器配套选择执行计划时,是否选择HashJoin,选择外表

MySQL8.0新特性——支持原子DDL语句

MySQL 8.0开始支持原子数据定义语言(DDL)语句.此功能称为原子DDL.原子DDL语句将与DDL操作关联的数据字典更新,存储引擎操作和二进制日志写入组合到单个原子事务中.即使服务器在操作期间暂停,也会提交事务,并将适用的更改保留到数据字典,存储引擎和二进制日志,或者回滚事务. 通过在MySQL 8.0中引入MySQL数据字典,可以实现Atomic DDL.在早期的MySQL版本中,元数据存储在元数据文件,非事务性表和存储引擎特定的字典中,这需要中间提交.MySQL数据字典提供的集中式事务

Mysql 8.0 新特性测试

Mysql 8.0 新特性测试 Role MySQL8.0版本添加了role特性,role是一种逻辑概念是权限的集合,可以将一个或以上的权限赋予给role,再将role赋给user.Oracle,Postgresql和Mariadb中早已存在role这个特性. create role role_test; grant select,insert,delete,update on zhongwc.tab01 to role_test; create user 'user1'@'%' identif

Visual Studio 2015与C#6.0新特性

Visual Studio 2015与C#6.0新特性 更多发现  admin  9个月前 (07-20)  4339浏览 今天,我们很高兴宣布下一代开发工具Visual Studio 2015的新特性,新的改进包括:支持跨平台的C++开发.新开源的.NET编译平台.C++11和C++14的支持,集成Apache的Cordova跨平台移动开发工具和ASP.NET5新框架,这些改进有大有小,零度在此摘录Visual Studio 2015在C#开发方面的新特性. 1.使用null条件运算符,在调用

atitit.j2ee 1.5 1.6 的不同跟 Servlet 3.0新特性总结

atitit.j2ee 1.5 1.6 的不同跟 Servlet 3.0新特性总结 1. jar比较,j2ee 1.6 添加了许多的jar 1 2. ,Servlet 3.0 2 2.1. 可插性  web片段 2 2.2. 异步处理 3 2.3. anno支持filter,sevlet,listen 3 2.4. 三.元数据和通用注释 3 2.5. 现有API的改进 HttpServletRequest,,HttpServletRequest,,ServletContext,,dynac fi