13.查询成本的计算(gold_axe)

执行计划:成本最低的方案
possible key: 查询中可能用到的索引

CREATE TABLE single_table (
    id INT NOT NULL AUTO_INCREMENT,
    key1 VARCHAR(100),
    key2 INT,
    key3 VARCHAR(100),
    key_part1 VARCHAR(100),
    key_part2 VARCHAR(100),
    key_part3 VARCHAR(100),
    common_field VARCHAR(100),
    PRIMARY KEY (id),

    KEY idx_key1 (key1),//
    UNIQUE KEY uk_key2 (key2),//唯一索引
    KEY idx_key3 (key3),//
    KEY idx_key_part(key_part1, key_part2, key_part3)//

) Engine=InnoDB CHARSET=utf8;

单表查询

查询例句:

SELECT * FROM single_table WHERE 
    key1 IN ('a', 'b', 'c') // idx_key1 
AND 
    key2 > 10 AND key2 < 1000// uk_key2
 AND 
    key3 > key2 // 不可能用到索引
AND 
    key_part1 LIKE '%hello%' //不可能用到索引
AND
    common_field = '123';//不可能用到索引

possible key:idx_key1,uk_key2

查询成本 有2种,
I/O成本:加载到内存的成功
CPU成本:读取,检测记录是否满足,对结果排序

mysql为每个表维护了统计信息, 有 Rows(大概几行) Data_length(基础索引多大,单位B)
一页16k,因此能算出聚簇索引有几页
这里假设97页,9693行

现在计算比较上一个查询成本:

  • 全表扫描成本 估算

I/O成本: 97(总页数)*1(I/O成本参数默认,可调)+1.1(微调值不用管)
CPU成本: 9693(行)* 0.2(成本常数)+1.0(微调值)

虽然,聚簇索引只有最下层的叶子节点是真的放着数据, 只要沿着最下层的双向链表 从左往右就能遍历了, 实际是不用遍历内节点的, 这里的估算比较粗暴, 但是就是这么估的

  • 用唯一索引 uk_key2 的成本估算

key2 > 10 AND key2 < 1000

1.把这个区间的二级索引全部读入磁盘, 的I/O成本 是1

就是查(10,1000)区间, 估算时 查询优化器认为, 一个区间的I/O成本 就是读取一页的成本

2.从中拿到主键id, 查看一条成本0.2
首先要沽出(10,1000)区间大概有几条记录(肯定少于1000-10),如果最左和最右相隔不远,就直接得出精确值,不然的话 平均每个页几条(统计左边10页) * 左右间有几页(往上找共同父节点)

注意: 这样直接去访问树, 来估算条数,叫index dive
真的去访问了, 这样这个得到估算值的本身的动作,就会产生成本
为了不让这个为了估算产生的成本太大, 如果 in(参数) 参数多于200就不用index dive, 而是直接:
Rows/Cardinality来估算条数
Rows: 统计的大概行数
Cardinality:基数,表示重复程度的,1是完全相同,和行数相等是每行都不相等
这种估算代价小,但是不怎么精确

这里假设是95
95 * 0.2 +0.01=19.01
3.凭着符合key2 > 10 AND key2 < 1000 的id 去聚簇索引拿到完整一条的记录(忽略不计), 主要是 查看对其他查询条件的满足(key1 IN ('a', 'b', 'c'), key3 > key2,key_part1 LIKE '%hello%' ,common_field = '123' 这些)
95*0.2

  • 普通二级索引 idx_key1 的成本估算

key1 IN ('a', 'b', 'c')

  1. 把3个单点区间读入磁盘, 还是和上文说的一样,一个区间当一页算
    3*1
  2. 同上, 查看1读入的数据拿到id, 需要先估满足条件的有几条(不是三条哦.key1不限制值不能相同), 和上文一样估, 这里即使一共118条件
    118*2+0.01
    3.同上, 用id回表(忽略不计), 查看完整的记录,应用其他筛选条件
    118*0.2=23.6

这里明显不能 Index Merge (idx_key1,uk_key2 并行查询然后合并 ), 因为二级索引是等值查询 是必要条件 (因为取交集必须是id是有序的取交集才快)

连接查询的成本

成本= 访问驱动表+ 驱动表扇出数* 单词访问被驱动表成本

扇出数的计算 叫 Condition filtering
主要靠猜, 没有筛选条件, 直接用驱动表的统计的大概Rows, key2 > 10 AND key2 < 1000 和上文说的一样 index dive

外连接的最优查询方案: 分别选择最优访问方法
外连接的最优查询方案:还要选择驱动顺序

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

推荐阅读更多精彩内容