189 8069 5689
常见的索引类型：哈希表、有序数组、搜索树。
网站的建设创新互联公司专注网站定制,经验丰富,不做模板,主营网站定制开发.小程序定制开发,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）无关了.
order为关键字，作为字段使用是需要加`引上，如下：
update test_t set `order`=5 where id=15;
建立索引，要使用离散度（选择度）更高的字段。
我们先来看一个重要的属性列的 离散度，
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.联合索引把散列性高（区分度高）的值放在前面