sql优化小记

mysql优化

1)left join 左连接 驱动表是右表; 右表 加索引,其他类似

2)join优化

永远用小结果集驱动大的结果集

优先优化NestedLoop的内层循环

保证join语句中被驱动表上join条件字段已经被索引

3)其他优化

当无法保证被驱动表的join条件字段被索引且内存资源充足的前提下,不要太吝啬joinBuffer的设置

尽量使用覆盖索引(只返回索引的查询(索引列和查询列一致)),减少select*

!=,is not null  ,is null 会导致索引失效

字符串不加单引号索引失效

少用or

索引失效



网上看的顺口溜:

带头大哥不能死

中间兄弟不能断

索引列上少计算

范围之后全失效

like 百分加右边

group by 表面上叫分组,分组之前必排序  会产生临时表

类似order by 

exists 可以理解为  将主查询的数据 放到主查询中做条件验证 根据验证结果(true or false)

来决定主查询的数据结果是否得以保留

order by 优化

尽可能在索引列上完成排序操作  遵照索引最佳做前缀法则

如果排序字段不在索引列上  filesort有2种算法

单路排序  多路排序

在sort_buffer中 方法b(多路算法法)比方法a(单路算法)要多占用很多空间,因为方法b是把所有字段都取出

所以有可能取出数据的总大小超出了sort_buffer的容量,导致每次只能读取sort_buffer

容量大小的数据  进行排序(创建temp文件 多路合并)  排完再取

sort_buffer大小的容量大小 再排...    从而多次I/O

本来想省一次I/O  反而导致了大量的I/O  反而得不偿失

优化策略:增大 sort_buffer_size 参数的设置

增大max_length_for_sort_data参数设置

少写select *

why

----------

为排序使用索引

1)mysql 2中排序方式:文件排序(using filesort),扫描有序索引排序(using index)

2)mysql能为排序与查询使用相同的索引



2020-04-16  19:23  北京今天刮大风 

网上看到一个问题 贴下截图


图1


图2

三者的区别

using index:使用覆盖索引的时候就会出现

using where:在查找使用索引的情况下,需要回表去查询所需的数据

using index condition:查找使用了索引,但是需要回表查询数据

using index & using where:查找使用了索引,但是需要的数据都在索引列中能找到,所以不需要回表查询数据

以上四点就能看出它们之前的区别,

或许有部分人都存在疑惑using index & using where和using index condition那个比较好,

从上面的的解释中就能看出是前者比较好,毕竟不需要回表查询数据,效率上应该比较快的



mysql 覆盖索引:

覆盖索引的定义:

如果一个索引包含(或覆盖)所有需要查询的字段的值,称为‘覆盖索引’。即只需扫描索引而无须回表。

只扫描索引而无需回表的优点:

    1.索引条目通常远小于数据行大小,只需要读取索引,则mysql会极大地减少数据访问量。

    2.因为索引是按照列值顺序存储的,所以对于IO密集的范围查找会比随机从磁盘读取每一行数据的IO少很多。

    3.一些存储引擎如myisam在内存中只缓存索引,数据则依赖于操作系统来缓存,因此要访问数据需要一次系统调用

    4.innodb的聚簇索引,覆盖索引对innodb表特别有用。(innodb的二级索引在叶子节点中保存了行的主键值,所以如果二级主键能够覆盖查询,则可以避免对主键索引的二次查询)

覆盖索引必须要存储索引列的值,而哈希索引、空间索引和全文索引不存储索引列的值,所以mysql只能用B-tree索引做覆盖索引。

当发起一个索引覆盖查询时,在explain的extra列可以看到using index的信息

理解MySQL回表:

回表就是先通过数据库索引扫描出数据所在的行,再通过行主键id取出索引中未提供的数据,即基于非主键索引的查询需要多扫描一棵索引树。



 慢查询日志:

--查看慢查询日志是否开启 及文件位置

show variables like 'slow_query%';

--默认慢查询时间 10s

show variables like 'long_query_time';

--将 slow_query_log 全局变量设置为“ON”状态 ,临时生效,mysql重启后就会失效

set global slow_query_log='ON';

--设置慢查询时间

set global long_query_time=3

换新绘画才能看到生效;

-- show profiles

show VARIABLES like 'profiling'

--默认OFF

show profiles;

/*Query_ID为#3步骤中show profiles列表中的Query_ID*/

show profile cpu,block io for query 132;

#1.show profile默认是关闭的,并且开启后只存活于当前会话,也就说每次使用前都需要开启。

#2.通过show profiles查看sql语句的耗时时间,然后通过show profile命令对耗时时间长的sql语句进行诊断。

#3.注意show profile诊断结果中出现相关字段的含义,判断是否需要优化sql语句

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

推荐阅读更多精彩内容