MySQL优化之索引基础,实战优化的基础知识

数据库设计总结

1.尽量避免过度设计,例如会导致及其复杂查询的schema设计,或者有很多列的表设计。
2.使用小而简单的合适数据类型,除非真实数据模型中有确切的需要,否则应该尽可能地避免使用NULL值。
3.尽量使用相同的数据类型存储相似或相关的值,尤其是需要在关联条件中使用的列。
4.注意可变长字符串,其在临时表和排序时可能导致悲观的按最大长度分配内存。
5.尽量使用整形定义标识列。
6.避免使用MySQL已经废弃的特性,例如指定浮点数的精度等。
7.小心使用ENUM和SET。虽然他们用起来很方便,但是不要滥用,否则有可能变成陷阱。

索引

BTree索引,是一种树结构,索引速度比全表查询速度快。
每个叶子节点即使MySQL中的一个页,默认每页16KB大小。
MySQL中InnoDB使用B+Tree,B+Tree中每个叶子节点都有一个指向先一个叶子节点的指针。

组合索引

InnoDB中BTree索引生效的情况【customer创建组合索引(last_name, first_name, email)】
匹配最左前缀:查找姓为MILLER的人,只使用索引的第一列。
explain select * from customer where last_name='MILLER';
全值匹配:全值匹配是指和索引中所有的列进行匹配,例如查找姓名为MARIA MILLER,email为MARIA.MILLER@sakilacustomer.org的人。
explain select * from customer where last_name='MILLER' and first_name='MARIA' and email='MARIA.MILLER@sakilacustomer.org';
匹配列前缀:可以匹配某一列值的开头部分,例如查找以M开头的姓的人。
EXPLAIN select * from customer where last_name like 'M%';
匹配范围值:查找姓大于等于WEINER的人。
EXPLAIN select * from customer where last_name>='WEINER';
精确匹配某一列并范围匹配另一列:查找所有姓为MILLER,且名字是字母M开头的人。即第一列last_name的全匹配,第二列first_name范围匹配。(也是前缀匹配)
EXPLAIN select * from customer where last_name='MILLER' and first_name like 'M%';

#如果不是按照索引的最左列开始查找,则无法使用索引【不从last_name列开始检索】
explain select * from customer where first_name='MARIA'  and email='MARIA.MILLER@sakilacustomer.org';
#不能跳过索引中的列【没有first_name列】
explain select * from customer where last_name='MILLER' and email>'SHEILA.WELLS@sakilacustomer.org';
#如果查询中有某个列的范围查询,则其右边所有列都无法使用索引优化查找【first_name为范围查找,email列无效】
explain select * from customer where last_name='MILLER' and first_name>'MARIA'
                                       and email='MELANIE.ARMSTRONG@sakilacustomer.org';
Hash索引,在MySQL中只有Memory引擎支持

当Hash索引中出现哈希冲突的时候,存储引擎需要遍历链表中所有的行,找到所有符合条件的数据。
冲突越多,索引代价越大。
<=> 并非 <>
Mysql 的 InnoDB引擎 有一个功能叫做“自适应哈希索引”。当MySQL发现某些索引值被频繁使用时,会在内存中基于BTree索引创建一个哈希索引。整个过程无法认为控制,仅可以通过innodb_adaptive_hash_index属性配置是否开启,默认开启该功能。

InnoDB聚簇索引(主键索引)

已满的页中,如果需要插入新的数据,会导致页分裂
InnoDB二级索引



Select id,name from tablename where name=’Rose’; #只需要遍历二级索引即可得到结果。

Myisam引擎索引

Myisam引擎中,主键索引与其他索引在结构上没有区别。

InnoDB中默认最大填充因子是页的15/16大小 MySQL默认每页16K 数据达到15K的时候, 分配到下一页。 不同页之间可能不是顺序的,只是通过一个指针相连。

InnoDB主键最好是连续递增的值,尽量避免使用UUID之类的长而无需的字符串。使用UUID做主键,在BTree的聚簇索引上,会导致插入速度慢,索引空间更大,其他二级索引空间也会更大。
索引空间变大的原因有两个,一个是由于主键字段更长,其次是因为页分裂和碎片(页不饱和)导致。

索引列的字段要尽可能小 因为BTree索引树高度页的大小以及页里面的数据大小决定的。数据越小,磁盘块存储的数据越多,树的高度越低,查询性能越高。

三星索引:

1、索引将相关的记录放到一起(Where子句后面的条件都可以使用索引,体现组合索引的利用)
2、索引中数据的顺序和查找中的排列顺序一致(利用索引的有序性直接得到排序结果)
3、索引中的列包含了查询中全部需要的列(利用索引中的值,直接得到查询结果,避免回表)

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 214,504评论 6 496
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 91,434评论 3 389
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 160,089评论 0 349
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,378评论 1 288
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,472评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,506评论 1 292
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,519评论 3 413
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,292评论 0 270
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,738评论 1 307
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,022评论 2 329
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,194评论 1 342
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,873评论 5 338
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,536评论 3 322
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,162评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,413评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,075评论 2 365
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,080评论 2 352

推荐阅读更多精彩内容