sql优化3

  • Select语句优化:
  1. 尽量避免全表扫描, where 及 order by 涉及的列上考虑建立索引
  2. 避免在SQL里做函数计算
  3. 避免索引的最左匹配原则失效
  4. 索引的范围至少要达到range
  5. 使用覆盖索引可以避免回表
  6. 避免在 where 子句中使用 不等于:!= 或 <>,not in 操作符,会造成索引失效
  7. 禁用or,所有使用or的地方,都可以使用unit all进行替换
  8. 慎用in,禁止not in,使用between以及exist很多时候是一个好的选择。in会使索引失效。
  9. 禁止where 条件中对字段进行表达式运算及函数操作
  10. 禁用select * from table,只查询需要的字段。
  11. 正确使用联合索引时,where中字段顺序与索引顺序应当一致,且最左侧字段必须避免索引失效
  12. 小表关联大表,from <left_table> <join_type> JOIN <right_table>
    若from table1 left join table2=》table1应该是小表,talbe2应该是大表
    若from table1 right join table2=》table2应该是小表,talbe1应该是大表
  13. 效率上来看:count(字段)<count(主键id)<count(1)≈count(),但应该注意业务逻辑的准确性,即使用不同的的count时,对null的行的处理是不一样的。且应该避免使用没有where条件count,即全表count,在有group by 的情况下,有时候组合索引会起到意想不到的作用
    count(
    )计数结果包括NUll
    count(1)计数结果包括NUll
    count(column)忽略Null
  14. 正确使用类型,避免隐式转换,索引失效,on条件及where条件
    错误的例子:select * from test where tu_mdn_str=13333333333;
    正确的例子:select * from test where tu_mdn_str='13333333333';
    特别当查询的字段是字符串时,等号右边的条件一定要用引号引起来标明这是一个字符串,否则会造成索引失效触发全表扫描。
  15. 涉及到统计聚合类的业务,应当对历史数据统计好进行存储,再组合上当前的数据进行查询
  16. Where字句中的连接顺序,MySQL采用从左往右,自上而下的顺序解析where子句,故过滤数据多的条件往前放,最快速度缩小结果集
  17. Unit 与Unit All的选择:Unit All不会去重,而Unit则会加上distinct,从则导致对整个临时表的数据做唯一性校验,这样自然会消耗更多
  18. 禁止在一张在表使用没有where语句,以及返回大批量的数据,所有大表的数据返回都应当分页
  19. Where与having的选择:除非一定要使用having,否则都使用where
  20. Group by: MySQL对所有GROUP BY col1,col2...的字段进行排序,在某些业务场景下,并不需要排序时,则可以指定ORDER By NULL禁止排序,避免排序结果的消耗
    where user_id is not null 可以使group by user_id时使用索引。
  21. Order by :
    用order by子句的重点是是否会产生filesort,order by不按索引顺序会出现using filesort。
    能不排序就不排序。若一定要排序,优先:通过有序索引顺序扫描直接返回有序数据:
    order by 条件要与where中条件一致,顺序一致,否则order by不会利用索引进行排序。
    其次使用filesort时,最好能使用单路排序算法进行排序,max_length_for_sort_data的大小和Query 语句所取出的字段类型大小总和来判定一次扫描算法还是双路排序算法。
    优化filesort:加大 max_length_for_sort_data 参数的设置;去掉不必要的返回字段;增大 sort_buffer_size 参数设置
    https://blog.csdn.net/weixin_34082854/article/details/93633860
  22. Limit优化:
    在索引排序完成排序分页的操作,最后根据主键关联回原表查询所需要的其他列内容;
    把limit m,n 转换成 limit n的查询,通过m,n计算出一个位置,使用where条件然后从这个位置开始limit n,例如:
    假设某张记录表,主键连续递增,中间不断层,则要先根据m,nt计算出id的位置,然后使用where id >位置 limit n进行分页
  23. 子查询优化:尝试转化成关联查询有时候是一个不错的选择,原则是相关子系统都可以转换成关联查询
  24. is null,is not null也无法使用索引。尽量设置初始值。
  25. like以通配符开头('%abc..')也会导致索引失效
    通过覆盖索引可以解决like '%字符串%'索引失效的问题。
  26. 范围查询阻断,联合索引的后续字段不能走索引。
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 218,546评论 6 507
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 93,224评论 3 395
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 164,911评论 0 354
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,737评论 1 294
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,753评论 6 392
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,598评论 1 305
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,338评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,249评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,696评论 1 314
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,888评论 3 336
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 40,013评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,731评论 5 346
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,348评论 3 330
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,929评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 33,048评论 1 270
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,203评论 3 370
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,960评论 2 355

推荐阅读更多精彩内容