mysql索引怎么更新 mysql索引升序

mysql之普通索引和唯一索引

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

网站的建设创新互联公司专注网站定制,经验丰富,不做模板,主营网站定制开发.小程序定制开发,H5页面制作!给你焕然一新的设计体验!已为咖啡厅设计等企业提供专业服务。

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）无关了.

mysql：更新唯一索引的值

order为关键字，作为字段使用是需要加`引上，如下：

update test_t set `order`=5 where id=15;

Mysql索引

建立索引，要使用离散度（选择度）更高的字段。

我们先来看一个重要的属性列的 离散度，

count(distinct(column_name)) : count(*) -- 列的全部不同值个数：所有数据行行数

数据行数相同的情况下，分子越大，列的离散度就越高。简单来说，如果列的重复值越多，离散度就越低，重复值越少，离散度就越高。

当字段值比较长的时候，建立索引会消耗很多的空间，搜索起来也会很慢。我们可以通过截取字段的前面一部分内容建立索引，这个就叫前缀索引。

创建一张商户表，因为地址字段比较长，在地址字段上建立前缀索引

create table shop(address varchar(120) not null);

alter table shop add key(address(12));  // 截取12个字符作为前缀索引是最优的吗？

问题是，截取多少呢？截取得多了，达不到节省索引存储空间的目的，截取得少了，重复内容太多，字段的散列度（选择性）会降低。怎么计算不同的长度的选择性呢？

先看一下字段在全部数据中的选择度计算公式：

select count(distinct address) / count(*) from shop;

select count(distinct left(address, n)) / count(*) as subn from shop;

count(distinct left(address,n)) / count(*) 的结果是会随着 n 的变大而变大。举个例子，现在有两个address（东大街长兴小区，东大街福乐小区），那么 distinct(address，2) distinct(address，3）

==所以，截取的长度越长就会越接近字段在全部数据中的选择度

==所以，我们要权衡索引大小和查询速度。

举个例子，通过不同长度去计算，与全表的选择性对比：

SELECT  COUNT(DISTINCT(address))/COUNT(*) sub,            -- 字段在全部数据中的选择度

COUNT(DISTINCT(LEFT(address,5)))/COUNT(*) sub5,  -- 截取前5个字符的选择度

COUNT(DISTINCT(LEFT(address,7)))/COUNT(*) sub7, 

COUNT(DISTINCT(LEFT(address,9)))/COUNT(*) sub9,

COUNT(DISTINCT(LEFT(address,10)))/COUNT(*) sub10,  -- 截取前10个字符的选择度

COUNT(DISTINCT(LEFT(address,11)))/COUNT(*) sub11,

COUNT(DISTINCT(LEFT(address,12)))/COUNT(*) sub12,

COUNT(DISTINCT(LEFT(address,13)))/COUNT(*) sub13,

COUNT(DISTINCT(LEFT(address,15)))/COUNT(*) sub15

FROM shop;

+--------+--------+--------+--------+--------+--------+--------+--------+--------+

| sub    | sub5  | sub7  | sub9  | sub10  | sub11  | sub12  | sub13  | sub15  |

+--------+--------+--------+--------+--------+--------+--------+--------+--------+

| 0.9993 | 0.0225 | 0.4663 | 0.8618 | 0.9734 | 0.9914 | 0.9943 | 0.9943 | 0.9958 |

+--------+--------+--------+--------+--------+--------+--------+--------+--------+

可以看到在截取 11 个字段时 sub11(0.9993) 就已经很接近字段在全部数据中的选择度 sub(0.9958)了，而且长度也相较后面更短一些， 综合考虑比较合适。

ALTER TABLE shop ADD KEY (address(11));

1.索引的个数不要过多（浪费空间，更新变慢）

2.在用于 where 判断 order 排序和 join 的（on）字段上创建索引

3.区分度低的字段，例如性别，不要建索引（离散度太低，导致扫描行数过多）

4.更新频繁的值，不要作为主键或者索引（页分裂）

5.不建议用无序的值作为索引，例如身份证、UUID（在索引比较时需要转为ASCII，并且插入时可能造成页分裂）

6.若在多个字段都要创建索引的情况下，联合索引优于单值索引

7.联合索引把散列性高（区分度高）的值放在前面