6-20MySQL

上节回顾:

1. 作用

优化查询,类似于书中的目录

2. 算法分类

Btree

Rtree

Hash

fulltext

gis

3. 聚集索引和辅助索引构成逻辑

4. 辅助索引细分

单列

多列(联合索引)

唯一

5. 索引树高度

1. 数据行 分表

2. 索引列值较长 前缀索引

3. 数据类型

6. 索引的管理操作

mysql> alter table t100w add index idx_k2(k2);

mysql> desc t100w

mysql> show index from t100w\G

mysql> alter table t100w add unique index idx_k1(k1);

mysql> alter table city add index idx_name(name(5));

mysql> alter table city add index idx_co_po(countrycode,population);

mysql> alter table city drop index idx_co_po;

7. 执行计划

7.1 作用

上线新的查询语句之前,进行提前预估语句的性能

在出现性能问题时,找到合理的解决思路

7.2 执行计划获取

mysql> desc  select * from oldboy.t100w where k2='EF12'\G

*************************** 1. row ***************************

          id: 1

  select_type: SIMPLE

        table: t100w

  partitions: NULL

        type: ref

possible_keys: idx_k2

          key: idx_k2

      key_len: 17

          ref: const

        rows: 293

    filtered: 100.00

        Extra: NULL

1 row in set, 1 warning (0.00 sec)

table: t100w

type: ref              索引的应用级别

possible_keys: idx_k2  可能会使用到的索引 

key: idx_k2   实际上使用的索引

key_len: 17   联合索引覆盖长度

rows: 293   查询的行数(越少越好)

Extra: NULL   额外的信息

7.3 执行计划的分析

type          索引的应用级别

ALL :  全表扫描,不走索引

没建立索引!!

建立索引不走的()!!!!

mysql> desc select * from t100w;

mysql> desc select * from t100w where k1='aa';

(辅助索引)

mysql> desc select * from t100w where k2 != 'aaaa';

mysql> desc select * from t100w where k2 like '%xt%';

Index :全索引扫描

mysql> desc select k2 from t100w;

range :索引范围扫描

辅助索引 : > < >= <= like ,  in  or   

主键: !=

mysql> desc select * from world.city where countrycode like 'C%'

mysql> desc select * from world.city where id!=3000;

mysql> desc select * from world.city where id>3000;

mysql> desc select * from world.city where countrycode in ('CHN','USA');

改写为:

desc

select * from world.city where countrycode='CHN'

union all

select * from world.city where countrycode='USA';

ref : 辅助索引等值查询

mysql> desc select * from city where countrycode='CHN';

eq_ref :在多表连接查询是on的条件列是唯一索引或主键

mysql> desc select a.name,b.name ,b.surfacearea

from city as a

join country as b

on a.countrycode=b.code

where a.population <100;

const,system : 主键或唯一键等值查询

mysql> DESC SELECT * from city where id=10;

Extra: NULL   额外的信息

using filesort

mysql> alter table city add index idx_co_po(countrycode,population);

7.4 explain(desc)使用场景(面试题)

题目意思:  我们公司业务慢,请你从数据库的角度分析原因

1.mysql出现性能问题,我总结有两种情况:

(1)应急性的慢:突然夯住

应急情况:数据库hang(卡了,资源耗尽)

处理过程:

1.show processlist;  获取到导致数据库hang的语句

2. explain 分析SQL的执行计划,有没有走索引,索引的类型情况

3. 建索引,改语句

(2)一段时间慢(持续性的):

1. 记录慢日志slowlog,分析slowlog

2. explain 分析SQL的执行计划,有没有走索引,索引的类型情况

3. 建索引,改语句

8. 索引应用规范

业务

1.产品的功能

2.用户的行为

"热"查询语句 --->较慢--->slowlog

"热"数据

8.1 建立索引的原则(DBA运维规范)

8.1.0 说明

为了使索引的使用效率更高,在创建索引时,必须考虑在哪些字段上创建索引和创建什么类型的索引。

那么索引设计原则又是怎样的?

8.1.1 (必须的) 建表时一定要有主键,一般是个无关列

略.回顾一下,聚集索引结构.

8.1.2 选择唯一性索引

唯一性索引的值是唯一的,可以更快速的通过该索引来确定某条记录。

例如,学生表中学号是具有唯一性的字段。为该字段建立唯一性索引可以很快的确定某个学生的信息。

如果使用姓名的话,可能存在同名现象,从而降低查询速度。

优化方案:

(1) 如果非得使用重复值较多的列作为查询条件(例如:男女),可以将表逻辑拆分

(2) 可以将此列和其他的查询类,做联和索引

select count(*) from world.city;

select count(distinct countrycode) from world.city;

select count(distinct countrycode,population ) from world.city;

8.1.3(必须的) 为经常需要where 、ORDER BY、GROUP BY,join on等操作的字段,

排序操作会浪费很多时间。

where  A B C      ----》 A  B  C

in

where A  group by B  order by C

A,B,C

如果为其建立索引,优化查询

注:如果经常作为条件的列,重复值特别多,可以建立联合索引。

8.1.4 尽量使用前缀来索引

如果索引字段的值很长,最好使用值的前缀来索引。

8.1.5 限制索引的数目

索引的数目不是越多越好。

可能会产生的问题:

(1) 每个索引都需要占用磁盘空间,索引越多,需要的磁盘空间就越大。

(2) 修改表时,对索引的重构和更新很麻烦。越多的索引,会使更新表变得很浪费时间。

(3) 优化器的负担会很重,有可能会影响到优化器的选择.

percona-toolkit中有个工具,专门分析索引是否有用

8.1.6 删除不再使用或者很少使用的索引(percona toolkit)

pt-duplicate-key-checker

表中的数据被大量更新,或者数据的使用方式被改变后,原有的一些索引可能不再需要。数据库管理

员应当定期找出这些索引,将它们删除,从而减少索引对更新操作的影响。

8.1.7 大表加索引,要在业务不繁忙期间操作

8.1.8 尽量少在经常更新值的列上建索引

8.1.9 建索引原则

(1) 必须要有主键,如果没有可以做为主键条件的列,创建无关列

(2) 经常做为where条件列  order by  group by  join on, distinct 的条件(业务:产品功能+用户行为)

(3) 最好使用唯一值多的列作为索引,如果索引列重复值较多,可以考虑使用联合索引

(4) 列值长度较长的索引列,我们建议使用前缀索引.

(5) 降低索引条目,一方面不要创建没用索引,不常使用的索引清理,percona toolkit(xxxxx)

(6) 索引维护要避开业务繁忙期

8.2 不走索引的情况(开发规范)

8.2.1 没有查询条件,或者查询条件没有建立索引

select * from tab;      全表扫描。

select  * from tab where 1=1;

在业务数据库中,特别是数据量比较大的表。

是没有全表扫描这种需求。

1、对用户查看是非常痛苦的。

2、对服务器来讲毁灭性的。

(1)

select * from tab;

SQL改写成以下语句:

select  * from  tab  order by  price  limit 10 ;    需要在price列上建立索引

(2)

select  * from  tab where name='zhangsan'          name列没有索引

改:

1、换成有索引的列作为查询条件

2、将name列建立索引

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

推荐阅读更多精彩内容