MySQL索引和字段类型，字段长度

首先是两个表， user_info 和 user_identify_info ，这两个表通过 user_id 关联。

user_info 中 user_id 字段是int(11)类型，主键索引

user_identify_info 中 user_id 是varchar类型，普通索引

执行结果如图，未使用到索引

将 user_identify_info 字段改为int(11)或者bigint类型，使用到索引

最后查到

1、字段是varchar类型，参数是int类型，不走索引

2、字段是varchar类型，参数是字符串，走索引

3、字段是int类型，参数是int类型，走索引

4、字段是int类型，参数是字符串，走索引

添加列delivery_address 字段扩展到1000

为这个字段添加单列索引，报异常出来，索引最大长度是3072 bytes

mysql5.7不报错，但会自动将索引长度限制在768

mysql8单列索引最长也是768

复合索引总长度不能超过768

MySQL目前主要的索引类型有下面几种:

与前面的普通索引类似,但是他的索引列的值必须是唯一的,所以叫唯一索引,但是这个索引字段如果是空值是可以的,具体创建方式如下:

主键索引是一种特殊的索引,一个表只能有一个主键,不允许有空值,一般是创建表的时候创建主键索引,而且一般习惯设置成自增的,因为对弈MySQL的底层B+树存储起来很方便

组合索引指多个字段上创建的索引,只有在查询时候,查询条件中使用了创建索引时的第一个字段,索引才会生效,他使用遵循最左前缀原则.

索引生效情况:

select * from table where name=1

select * from table where name=1 and city=2

select * from table where name=1 and city=2 and age=3

索引不生效情况:

select * from table where name=1 and age=3

select * from table where city=2 and age=3

select * from table where age=3

select * from table where city=2

这个遵循的是最左原则,具体MySQL底层对联合索引的存储以及为什么是最左原则,参考本人另外一篇文章最后一段就能看明白

https://www.jianshu.com/p/99aabf9611a3

全文索引主要是用来查找文本中的关键字,而不是直接与索引中的值相比较.fulltext索引跟其他索引大不相同,他更像是一个搜索引擎,而不是简单的where 语句的参数匹配,fulltext索引配合match(匹配)和against(反对) *** 作使用,而不是一般的where语句加上like,他可以在create table,alter table,create index使用

常见的索引类型：哈希表、有序数组、搜索树。

mysql之普通索引和唯一索引。

执行查询的语句是 select id from T where k=5

这个查询语句在索引树上查找的过程，先是通过 B+ 树从树根开始，按层搜索到叶子节点，也就是图中右下角的这个数据页，然后可以认为数据页内部通过二分法来定位记录。

InnoDB的索引组织结构：

change buffer:持久化的数据。InnoDB将更新 *** 作缓存在 change buffer中,也就是说,change buffer 在内存中有拷贝，也会被写入到磁盘，主要节省的则是随机读磁盘的IO消耗。

change buffer 只限于用在普通索引的场景下，而不适用于唯一索引.

merge:将 change buffer 中的 *** 作应用到原数据页，得到最新结果的过程。

merge执行流程：

1、从磁盘读入数据页到内存

2、从change buffer里找出这个数据页的change buffer记录，依次应用，得到新版数据页

3、写redo log,这个redo log包含了数据的变更和change buffer的变更。

change buffer 用的是 buffer pool 里的内存，因此不能无限增大。change buffer 的大小，可以通过参数 innodb_change_buffer_max_size=50 表示 change buffer 的大小最多只能占用 buffer pool 的 50%。

如果要在这张表中插入一个新记录 (4,400) 的话，InnoDB 的处理流程是怎样的。

第一种情况是，这个记录要更新的目标页在内存中

这时，InnoDB 的处理流程如下：

第二种情况是，这个记录要更新的目标页不在内存中

这时，InnoDB 的处理流程如下：

mysql>insert into t(id,k) values(id1,k1),(id2,k2)当前 k 索引树的状态，查找到位置后，k1 所在的数据页在内存 (InnoDB buffer pool) 中，k2 所在的数据页不在内存中。

分析这条更新语句，你会发现它涉及了四个部分：内存、redo log（ib_log_fileX）、 数据表空间（t.ibd）、系统表空间（ibdata1）。这条更新语句做了如下的 *** 作（按照图中的数字顺序）：

带change buffer的更新过程：

select * from t where k in (k1, k2) ,如果读语句发生在更新语句后不久，内存中的数据都还在，那么此时的这两个读 *** 作就与系统表空间（ibdata1）和 redo log（ib_log_fileX）无关了.

---