그냥 간단 B 트리 인덱스를 배울 수있는 마지막 시간 B-나무에 대해 이야기
각 B 트리 노드에있어서,
1. 키워드에 포함 된 노드의 수입니다.
부모 노드 2. 포인터
3. 키워드
4. 자식 노드에 대한 포인터 포인트
B- 트리에 대한 규칙
1.M 차 B-트리의 각 노드는 m 자식 노드를 가질 수 루트 노드는 적어도 두 개의 서브를 가진
2. (키) 루트 노드 키의 개수는 1 내지 m-1 번째이고, 각 비 루트 노드가 적어도 [m / 2] 개의 (반올림) 자식 노드, 키워드 수 있어야 [m / 2] -1 m-1 번째의 숫자
B-트리 성능
이 공식은 작성하는 방법과 추론 툿를 모르는 방법이다. 그러나 그 결과는 알 수있다 (각 2로 나눈 내부 N 데이터 체크 가정하면,이 데이터를 찾을이 수회에 더하여 필요) 횟수 (M)와, 순서와 무관 B 트리 이진 검색의 성능에 상당 .
전체 텍스트 인덱스 (전체 텍스트 인덱스, 가장 왼쪽 접두사 지수)
저장 구조 1. 정규 텍스트 인덱스는 주로 내가 쿼리처럼 필요로하는 문에 비 효율성을 해결하기 위해, B-트리입니다. 그것은 오직 해결과 같은 쿼리의 '%를 xxx는'할 수있다
2. 같은 문자열 ABC으로 전체 키워드 정보 (기준 주요 데이터 배열, 다음 문자열의 인덱스 AB처럼 사용하는 경우 만 순서는 쿼리 경우, 왼쪽에서 오른쪽으로 세 개의 A, AB, ABC, 메모를 가지고 % AB)는 즉시 AB와 ABC를 찾는 데 도움이 될 것입니다
일반 인덱스
대부분의 경우 우리는 B 트리 인덱스를 사용
인덱스 작업
인덱스를 생성 1.MySql
TABLE_NAME 인덱스의 인덱스 _ 생성 (열 (길이))
인덱스 INDEX_NAME를 추가 table_name 테이블을 변경 (열 (길이))
왜 길이를 추가 할 수 있습니까? 너무 긴 경우, 너무 많은 디스크 공간 때문에
(table_name 테이블을 생성
아이디 INT NOT NULL AUTO_INCREMENT,
표제 VARCHAR (32)
기본 키 (ID),
인덱스 INDEX_NAME (제목 (길이))
)
2.보기 색인
TABLE_NAME에서 인덱스를 보여
TABLE_NAME 만은 MySQL의 쇼 키
기본 기본 키는 B 트리 인덱스가, InnoDB는 기본 인덱스 B- 트리가 추가
3. 삭제 색인
TABLE_NAME에 인덱스 인덱스 _ 드롭
테이블 TABLE_NAME 드롭 인덱스 인덱스 _ 변경
기본 키를 드롭 TABLE_NAME 테이블을 변경
유일한 인덱스
인덱스 컬럼의 값이 고유해야하지만, 널 (null)을 허용해야한다는 것을 제외하고는 유사한 일반 인덱스 (다른 기본 키). 이 복합 인덱스 인 경우, 열이 가치 조합은 고유 및 일반 인덱스와 유사한 방법을 만들 수 있어야합니다
고유 인덱스를 생성
TABLE_NAME에 고유 인덱스의 인덱스 _를 만드는 (열 (길이))
독특한 인덱스 _ 추가 table_name 테이블을 변경 (열 (길이))
(table_name 테이블을 생성
아이디 INT NOT NULL AUTO_INCREMENT,
표제 VARCHAR (32)
기본 키 (ID),
고유 인덱스 _ (제목 (길이))
)
전체 텍스트 색인
전체 텍스트 인덱스는 MyISAM 테이블을 사용할 수 있습니다. 부분을 변경 사용 후 테이블 문을 생성하거나 생성 된 테이블이나 테이블에 인덱스를 만들 추가로 CHAR, VARCHAR, 텍스트 열을 만들 수 있습니다
가능한 한 먼저 전체 텍스트 인덱스는 다음 데이터 가져 오기 설정하지 않고, 전체 텍스트 인덱스를 생성 할 테이블을 설정 한 후 데이터를 가져 오는 것입니다으로 (그러나 데이터의 양이 너무 많으면를, 전체 텍스트는 매우 많은 시간과 하드 디스크를 색인)
전체 텍스트 인덱스 만들기
create fulltext index index_name on table_name (column(length))
alter table table_name add fulltext index_name(column)
create table table_name(
id int not null auto_increment,
title varchar(32),
primary key(id),
fulltext index_name(title))
)
组合索引(最左前缀)
将多个列组合成一个索引
举个栗子：
create table article（id int not null,title varchar(255) ,time date） 针对title 和 time 建立组合索引：
alter table article add index index_title_time (title(50),time(10))相当于建立了下边两组组合索引 （title（50）取的是前50个字符）
--title，time
--title
至于为什么没有time这个索引。MySql定义的最左前缀，就是这么定的，从最左边开始组合
如果使用 select * from article where time =1234567890 或者 select * from article where time=1234567890 and title='张三';就不会使用到上面的索引
创建组合索引
create index index name on table_name (column1(length),column2(length).....)
索引的优化
索引虽好，但是也不要贪杯哦。因为，索引是针对查询的一种提高效率的方式。但是如果增删改过于频繁的话，每次进行增删改都有可能去重构索引。
1.无效的索引：如果列中存在Null值，则不会被包含在索引中（这一行无效）。组合索引如果有一列包含null值，则这一列对于组合索引来说无效。所以在数据库设计时不要让字段默认值为null（可以设定默认值）
2.索引的长度尽量要短，基本上在char（255）范围内，截取前10个或者20个字符就能保证索引唯一。短索引不仅可以提高查询速度，还能节省磁盘空间和IO操作。
3.MySql查询只使用一个索引，因此如果where 子句已经使用了索引。那么order by 中的列是不会使用索引的。如果数据库的默认排序符合你的需求，就不要使用order by 了，尽量不要包含多个列的排序，如果需要最好将这些列创建复合索引。
（如果想看数据库的查询方式可以使用 explain + 查询语句）
4.尽量不要使用like ，如果使用 ，则 like ‘%aaa% ’不会使用索引 而 like ‘aaa%’会使用索引
5.不要再列上面进行运算
比如：select * from users where year（date）<2007 将会计算date列上的每一行的字段，索引失效，全表扫描
可以改成：select * from users where date < '2007-1-1'
索引总结
1.MySQL 在 < <= = > <= between in 以及某些时候的like（不用% 或者 _ 开头）的情形下面才使用索引（嘟嘟猜测不同的操作符会导致索引的使用率不同），每一张表可以建立最多16个索引，但是太多并没有什么卵用
2. ！= ， not in 等这种操作符也会使用到索引，想要查询是否用到索引以及是否为全表扫描。可以使用 explain + 查询语句 查看具体信息
常见优化策略
1.尽量避免全表扫描。（最好where 或者 order by 上面建立索引）
2.避免在where 上进行null 判断，否则会导致引擎放弃索引是用全表扫描（设置默认值为0等）
3.避免使用不等值判断，否则引擎会放弃使用索引而进行全表扫描
4.避免使用or逻辑 （全表扫描）
select id from t where num=10 or num=20
可以改成
select id from t where num = 10
union all
select id from t where num = 20
5.慎用in 和not in 逻辑（全表扫描）
6.注意模糊查询（%在前面会导致全表扫描）
如果必须用%开头，则推荐使用全文搜索引擎
7.避免查询条件中字段计算（会导致每个字段都进行计算）
8.避免在查询条件中对字段机型函数操作（原因同上）
select id from t where substring(name,1,3) = 'abc'
优化成 select id from t where name like 'abc%'
9.使用复合索引必须用到第一个字段才会用到索引
10.表格字段尽量使用数字类型字段，数字类型与字符串类型相比，搜索引擎会逐一比较每一个字符
11.查询字段越多返回效率越低，所以尽量不要使用*
大总结：
到了这里嘟嘟的数据库到底优化啥了都就算是初步的写完了（还有后续），第一个原因是嘟嘟在网上扒的视频资料没有了。嘟嘟也相信这份资料也是一份简单的介绍。比如explain + 查询语句下面的type项下有好多的选项（ref ，range ，all ，index 等等）都没有提及，还有什么MySql和MyCat的分库分表什么的。嘟嘟也知道什么东西都不能一蹴而就，所以这个MySql的文章还是没有写完。以后嘟嘟自己学习的过程中如果发现MySQL实现优化的细节，还会继续写567等等。。。
写这个博客相当于对着视频记笔记。初衷也是为了和面试官对吹，但是发现这些东西好像不够吹。所以嘟嘟还需要压榨时间效率。去深入学习编程，学习数据库等等。这个系列的东西，嘟嘟准备停一下。放空放空脑子。巩固一下这知识。最后勉励一下自己，再努力的压榨一下自己的时间利用率，提升自己。去做自己认为会往更好的方向发展的事情。毕竟在这个年代，放松毫厘，随着时间推移，会差之百里。挣扎，加油。