优化前 SELECT*  FROM erp_helei mg WHERE mg.num = 602   AND mg.pid   IN   (10002559,10002561,10002562,10002563,10002564,10002598,10002599,10002600,10002601,10002602,10002603,10002604,10002648,10002649,10002667,10002668,10002676,10002558) 优化后 SELECT*  FRO

如果delete语句带有查询,写法不对会导致不走索引. 简单粗暴的办法:拆两条sql,一条查询,一条delete ======================= [不走索引的写法] DELETE FROM goods_item_combo_group_item_history WHERE group_id IN (SELECT id FROM goods_item_combo_group_history WHERE lease_code = 'schjyzzh' AND item_code =

你可以认为联合索引是闯关游戏的设计 例如你这个联合索引是state/city/zipCode 那么state就是第一关 city是第二关, zipCode就是第三关 你必须匹配了第一关,才能匹配第二关,匹配了第一关和第二关,才能匹配第三关 你不能直接到第二关的 索引的格式就是第一层是state,第二层才是city 上面举例介绍来源 https://zhidao.baidu.com/question/1863364017408156387.html mysql sql 中如果使用了 not in

第一:选择唯一性索引 唯一性索引的值是唯一的,可以更快捷的通过该索引来确定某条记录. 2.索引的列为where 后面经常作为条件的字段建立索引 如果某个字段经常作为查询条件,而且又有较少的重复列或者是唯一咧可以考虑作为索隐列 经常作为查询条件的列作为索引会提高速度 3.位经常需要进行排序.分组和联合操作的的字段建立索引. order by  group by  distinct union 这种情况下在查询的时候排序会浪费很多的时间, 如果为其建立索引可以有效的避免排序操作. 4.限制索引的的数

需要修改阿里云中的MYSQL 配置参数 : eq_range_index_dive_limit 阿里云上默认是 10 , 这个参数 表示 in 查询 条件超过 10 个 就不走索引,走全表扫描.如果我们分页的数量超过10并且条件中使用了in,那么就需要修改这个参数 修改后

说明 在MySQL中,并不是你建立了索引,并且你在SQL中使用到了该列,MySQL就肯定会使用到那些索引的,有一些情况很可能在你不知不觉中,你就“成功的避开了”MySQL的所有索引. 索引列参与计算 如果where条件中age列中使用了计算,则不会使用该索引.如果需要计算,千万不要计算到索引列,想方设法让其计算到表达式的另一边去. SELECT `sname` FROM `t_stu` WHERE `age`=20; -- 会使用索引 SELECT `sname` FROM `t_stu` WH

SQL语句优化 1 企业SQL优化思路 1.把一个大的不使用索引的SQL语句按照功能进行拆分 2.长的SQL语句无法使用索引,能不能变成2条短的SQL语句让它分别使用上索引. 3.对SQL语句功能的拆分和修改 4.减少"烂"SQL由运维(DBA)和开发交流(确认),共同确定如何改,最终由DBA执行 5.制定开发流程 2 不适合走索引的场景 1.唯一值少的列上不适合建立索引或者建立索引效率低.例如:性别列 2.小表可以不建立索引,100条记录. 3.对于数据仓库,大量全表扫描的情况,建索

1.WHERE字句的查询条件里有不等于号(WHERE column!=…),MYSQL将无法使用索引 2.类似地,如果WHERE字句的查询条件里使用了函数(如:WHERE DAY(column)=…),MYSQL将无法使用索引 3.在JOIN操作中(需要从多个数据表提取数据时),MYSQL只有在主键和外键的数据类型相同时才能使用索引,否则即使建立了索引也不会使用 4.如果WHERE子句的查询条件里使用了比较操作符LIKE和REGEXP,MYSQL只有在搜索模板的第一个字符不是通配符的情况下才能使

  当一个表有多条索引可走时,  Mysql  根据查询语句的成本来选择走哪条索引, 联合索引的话, 它往往计算的是第一个字段(最左边那个), 这样往往会走错索引. 如: 索引Index_1(Create_Time, Category_ID), Index_2(Category_ID) 如果每天的数据都特别多, 而且有很多category, 但具体每个category的记录不会很多. 当查询SQL条件为select -where create_time -.and category_id=..时

数据库的索引非常重要,基本面试数据库的问题都在索引上,所以这里小编整理出来,一方面为了自己复习,一方面也方便大家. 一,索引前传 在了解数据库索引之前,首先有必要了解一下数据库索引的数据结构基础,那么什么样的数据结构可以作为索引呢? B-tree是最常用的用于索引的数据结构.因为它们是时间复杂度低, 查找.删除.插入操作都可以可以在对数时间内完成.另外一个重要原因存储在B-Tree中的数据是有序的.数据库管理系统(RDBMS)通常决定索引应该用哪些数据结构.但是,在某些情况下,你在创建索引时可以

一.索引的介绍 二 .索引的作用 三.常见的几种索引: 3.1 普通索引 3.2 唯一索引 3.3 主键索引 3.4 组合索引 四.索引名词 五.正确使用索引的情况 什么是最左前缀呢? 六.索引的注意事项 七.执行计划 八.慢日志记录 九.分页性能相关方案 最优的解决方案 一.索引的介绍 数据库中专门用于帮助用户快速查找数据的一种数据结构.类似于字典中的目录,查找字典内容时可以根据目录查找到数据的存放位置,然后直接获取. 二 .索引的作用 约束 和 加速查找 三.常见的几种索引: - 普通索引

看到很多网上谈优化mysql的文章,发现很多在谈到mysql的null是不走索引的,在此我觉得很有必要纠正下这类结论.mysql is null是有索引的,而且是很高效的,(版本:mysql5.5)表结构如下: CREATE TABLE `student` ( `stu_no` ) unsigned zerofill NOT NULL AUTO_INCREMENT COMMENT '学员编号', `stu_name` ) CHARACTER SET utf8 DEFAULT NULL COMME

一,索引前传 在了解数据库索引之前,首先有必要了解一下数据库索引的数据结构基础,那么什么样的数据结构可以作为索引呢? B-tree是最常用的用于索引的数据结构.因为它们是时间复杂度低, 查找.删除.插入操作都可以可以在对数时间内完成.另外一个重要原因存储在B-Tree中的数据是有序的.数据库管理系统(RDBMS)通常决定索引应该用哪些数据结构.但是,在某些情况下,你在创建索引时可以指定索引要使用的数据结构. B+是一个树数据结构,通常用于数据库和操作系统的文件系统中,B+树的特点是能够保持数据稳

一.创建索引需要关注什么? 1.关注基数列唯一键的数量: 比如性别,该列只有男女之分,所以性别列基数是2: 2.关注选择性列唯一键与行数的比值,这个比值范围在0~1之前,值越小越好: 其实,选择性列唯一键与行数的比值,只要列值区分度越高,这个比值就会相对越小 3.where like关键字的前面使用%会全表扫描,不走索引 4.禁止使用select,建议使用select <字段…>,因为select 会读取大量数据,不利于索引覆盖技术: 5.大批量导入数据的优化方法: (1)先导入数据,等待数据

一.什么是索引 一般的应用系统,读写比例在10:1左右,而且插入操作和一般的更新操作很少出现性能问题,遇到最多的,也是最容易出问题的,还是一些复杂的查询操作,所以查询语句的优化显然是重中之重. 在数据量和访问量不大的情况下,mysql访问是非常快的,是否加索引对访问影响不大.但是当数据量和访问量剧增的时候,就会发现mysql变慢,甚至down掉,这就必须瑶考虑优化sql了,给数据库建立正确合理的索引,是mysql优化的一个重要手段. 索引的目的在于提高查询效率,可以类比字典,如果要查“mysql

1:索引类型 1.1 B-tree索引 注: 名叫btree索引,大的方面看,都用的平衡树,但具体的实现上, 各引擎稍有不同, 比如,严格的说,NDB引擎,使用的是T-tree   Myisam,innodb中,默认用B-tree索引 但抽象一下---B-tree系统,可理解为”排好序的快速查找结构”. (排好序特别有利于范围查询) 1.2 hash索引 在memory表里,默认是hash索引, hash的理论查询时间复杂度为O(1) 解释:任意给定一行数据一次性就能在数据库中找到. 疑问: 既

[笔记]MySQL学习之索引 一 索引简单介绍 索引,是数据库中专门用于帮助用户快速查询数据的一种数据结构.类似于字典中的目录,查找字典内容时可以根据目录查找到数据的存放位置,然后直接获取即可. 普通索引:仅加速查询 唯一索引:加速查询 + 列值唯一(可以有null) 主键索引:加速查询 + 列值唯一 + 表中只有一个(不可以有null) 组合索引:多列值组成一个索引,专门用于组合搜索,其效率大于索引合并 全文索引:对文本的内容进行分词,进行搜索 索引合并:使用多个单列索引组合搜索 覆盖索引:s

日期类型可以直接和string格式的字符串比较 select * from xxx where event_time>'2018-06-02' 可以使用索引, mysql默认会把后面的字符串转成date类型.可以使用between and select * from xxx where date(event_time)>'2018-06-02'   不能使用索引 如果时间戳日期和时间都要比较, 最好使用两个字段保存这个时间戳, 这样可以利用索引 select * from xxx where

前言 又和大家见面了!又两周过去了,我的云笔记里又多了几篇写了一半的文章草稿.有的是因为质量没有达到预期还准备再加点内容,有的则完全是一个灵感而已,内容完全木有.羡慕很多大佬们,一周能产出五六篇文章,给我两个肝我都不够.好了,不多说废话了... 最近在线上环境遇到了一次SQL慢查询引发的数据库故障,影响线上业务.经过排查后,确定原因是SQL在执行时,MySQL优化器选择了错误的索引(不应该说是"错误",而是选择了实际执行耗时更长的索引).在排查过程中,查阅了许多资料,也学习了下MySQ

微信搜『烟雨星空』,获取最新好文. 前言 最近,有一个业务需求,给我一份数据 A ,把它在数据库 B 中存在,而又比 A 多出的部分算出来.由于数据比较杂乱,我这里简化模型. 然后就会发现,我去,这不就是 not in ,not exists 嘛. 那么问题来了,in, not in , exists , not exists 它们有什么区别,效率如何? 曾经从网上听说,in 和 exists 不会走索引,那么事实真的是这样吗? 带着疑问,我们研究下去. 注意: 在说这个问题时,不说明 MySQ