首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

MySQL SQL优化之覆盖索引

前些天,有个同事跟我说:“我写了个SQL,SQL很简单,但是查询速度很慢,并且针对查询条件创建了索引,然而索引却不起作用,你帮我看看有没有办法优化?”。...数据量:316977 这个数据量还是比较小的,不过如果SQL足够差,一样会查询很慢。...我们先来看下执行时间,然后再来分析为什么没有利用索引扫描。 执行时间:260ms ? 的确,执行时间太长了,如果表数据量继续增长下去,性能会越来越差。...也放到索引中。...执行计划显示查询会利用覆盖索引,并且只扫描了1000行数据,查询的性能应该是非常好的。 执行时间:13ms ? 从执行时间来看,SQL的执行时间提升到原来的1/20,已经达到我们的预期。

1.8K60
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    为什么我使用了索引,查询还是慢?

    如果是更极端的情况,比如,这个数据库上CPU压力非常的高,那么可能第2个语句的执行时间也会超过long_query_time,会进入到慢查询日志里面。...使用索引只是表示了一个SQL语句的执行过程,而是否进入到慢查询是由它的执行时间决定的,而这个执行时间,可能会受各种外部因素的影响。换句话来说,使用了索引你的语句可能依然会很慢。...所以即使explain的结果里写的KEY不是NULL,实际上也可能是全表扫描的,因此InnoDB里面只有一种情况叫做没有使用索引,那就是从主键索引的最左边的叶节点开始,向右扫描整个索引树。...name字段修改的时候也会自动修改。...这样这个语句的执行过程,就只需要扫描联合索引的100万行,并回表100万次,这个优化的本质是我们创建了一个更紧凑的索引,来加速了查询的过程。

    1K41

    为什么我使用了索引,查询还是慢?

    如果是更极端的情况,比如,这个数据库上CPU压力非常的高,那么可能第2个语句的执行时间也会超过long_query_time,会进入到慢查询日志里面。...使用索引只是表示了一个SQL语句的执行过程,而是否进入到慢查询是由它的执行时间决定的,而这个执行时间,可能会受各种外部因素的影响。换句话来说,使用了索引你的语句可能依然会很慢。...所以即使explain的结果里写的KEY不是NULL,实际上也可能是全表扫描的,因此InnoDB里面只有一种情况叫做没有使用索引,那就是从主键索引的最左边的叶节点开始,向右扫描整个索引树。...name字段修改的时候也会自动修改。...这样这个语句的执行过程,就只需要扫描联合索引的100万行,并回表100万次,这个优化的本质是我们创建了一个更紧凑的索引,来加速了查询的过程。

    2.4K40

    MYSQL日志-慢查询日志

    : 该参数定义了SQL执行时间被判定为慢查询的阈值,默认单位为秒,默认值为10;慢查询只会记录执行时间大于该阈值的SQL,恰好等于该阈值的SQL将不会被记录。...log_queries_not_using_index : 该参数描述了是否需要将未使用索引的SQL记录到慢查询日志中去,(即使它执行起来可能并不慢)ON:开启 OFF:关闭 log_throttle_queries_not_using_index...为了增加查询效率,你也可以创建相关索引。慢查询存储方式修改为TABLE后就不再写log。...总结:mysql慢查询不是默认开启的,需要修改参数slow_query_log=ON开启;慢查询中记录的不一定都是执行时间超过阈值的SQL也有可能是未使用到索引的SQL;慢查询并不一定是日志log文件方式存储...,也可以使用表存储。

    4.7K10

    为什么我使用了索引,查询还是慢?「建议收藏」

    如果是更极端的情况,比如,这个数据库上CPU压力非常的高,那么可能第2个语句的执行时间也会超过long_query_time,会进入到慢查询日志里面。...使用索引只是表示了一个SQL语句的执行过程,而是否进入到慢查询是由它的执行时间决定的,而这个执行时间,可能会受各种外部因素的影响。换句话来说,使用了索引你的语句可能依然会很慢。...所以即使explain的结果里写的KEY不是NULL****,实际上也可能是全表扫描的,因此InnoDB里面只有一种情况叫做没有使用索引,那就是从主键索引的最左边的叶节点开始,向右扫描整个索引树。...字段修改的时候也会自动修改。...这样这个语句的执行过程,就只需要扫描联合索引的100万行,并回表100万次,这个优化的本质是我们创建了一个更紧凑的索引,来加速了查询的过程。

    46030

    为什么我使用了索引,查询还是慢?

    如果是更极端的情况,比如,这个数据库上CPU压力非常的高,那么可能第2个语句的执行时间也会超过long_query_time,会进入到慢查询日志里面。...使用索引只是表示了一个SQL语句的执行过程,而是否进入到慢查询是由它的执行时间决定的,而这个执行时间,可能会受各种外部因素的影响。换句话来说,使用了索引你的语句可能依然会很慢。...所以即使explain的结果里写的KEY不是NULL,实际上也可能是全表扫描的,因此InnoDB里面只有一种情况叫做没有使用索引,那就是从主键索引的最左边的叶节点开始,向右扫描整个索引树。...name字段修改的时候也会自动修改。...这样这个语句的执行过程,就只需要扫描联合索引的100万行,并回表100万次,这个优化的本质是我们创建了一个更紧凑的索引,来加速了查询的过程。

    22610

    100-为什么数据库运行越来越慢? 了解一下服务

    T1表的id字段上有索引....: 当T1表记录数达到2000w(表名tbig)时, 执行时间来到了18.86秒,加上执行频率较高,系统已经不堪重负, 而且这个数据库的最终业务用户的使用体验也会大幅下降: 如何解决这个问题?...如果客户有信创需求, 说不定还会把这个库迁移到分布式数据库: 把大表数据打散到多台服务器处理, 也算是一种解决办法....这样一个SQL, 即使每天执行几百万次, 对数据库来说也是完全没有任何压力. 而且对业务用户来说, 会体验飞一般的感觉....,会带来严重的性能隐患)/业务逻辑的实现方法(在大表上频繁模糊查询,并发修改相同记录导致行锁等)/ 绑定变量的使用 ....

    24430

    命中索引一定能提高查询速度吗?

    以下是一些可能导致索引命中但查询速度依然缓慢的情况: 查询复杂性 多表查询:如果查询涉及多个表的连接、复杂的计算或子查询,即使命中索引,数据库仍然需要花费大量时间来处理这些复杂的操作。...如果索引的选择性较低(例如,某个字段的值重复率很高),即使命中索引,查询的效率也可能不高。...解决方案: 组合索引:如果低选择性字段与其他高选择性字段组合使用,可能会提高查询性能。...选择性越高,索引列中的每个值代表的行数就越少。这样,数据库就可以更快地定位符合条件的行。 选择性越低,每个值代表的行数就越多,这将需要更长的时间来查找符合条件的行。...过多的索引 虽然索引可以提高查询速度,但过多的索引会导致性能下降。每个索引都需要占用存储空间,并增加维护成本。

    9710

    为什么我使用了索引,查询还是慢?

    如果是更极端的情况,比如,这个数据库上CPU压力非常的高,那么可能第2个语句的执行时间也会超过long_query_time,会进入到慢查询日志里面。...使用索引只是表示了一个SQL语句的执行过程,而是否进入到慢查询是由它的执行时间决定的,而这个执行时间,可能会受各种外部因素的影响。换句话来说,使用了索引你的语句可能依然会很慢。...所以即使explain的结果里写的KEY不是NULL,实际上也可能是全表扫描的,因此InnoDB里面只有一种情况叫做没有使用索引,那就是从主键索引的最左边的叶节点开始,向右扫描整个索引树。...name字段修改的时候也会自动修改。...这样这个语句的执行过程,就只需要扫描联合索引的100万行,并回表100万次,这个优化的本质是我们创建了一个更紧凑的索引,来加速了查询的过程。

    55220

    掌握这几个技巧,以后用MySQL查询总比别人快一步!

    如果是更极端的情况,比如,这个数据库上CPU压力非常的高,那么可能第2个语句的执行时间也会超过long_query_time,会进入到慢查询日志里面。...使用索引只是表示了一个SQL语句的执行过程,而是否进入到慢查询是由它的执行时间决定的,而这个执行时间,可能会受各种外部因素的影响。换句话来说,使用了索引你的语句可能依然会很慢。...所以即使explain的结果里写的KEY不是NULL,实际上也可能是全表扫描的,因此InnoDB里面只有一种情况叫做没有使用索引,那就是从主键索引的最左边的叶节点开始,向右扫描整个索引树。...name字段修改的时候也会自动修改。...这样这个语句的执行过程,就只需要扫描联合索引的100万行,并回表100万次,这个优化的本质是我们创建了一个更紧凑的索引,来加速了查询的过程,读者福利:整理好的MySQL实战笔记。

    68600

    高级SQL优化之过滤条件下推优化(FPPD)

    改写前的执行计划 在c_nationkey和s_nationkey有索引,即使数据库优化器利用索引避免全表扫描;但是由于过滤条件nation = 100没有下推至数据表,其代价和执行时间仍然是比较大的,...改写后的执行计划 FPPD将条件nation = 100下推到UNION子查询的两个分支,使得后续的分组和排序运算的输入大大减少,整体的执行时间也降低到0.32ms。...3* 优化过程解析 可以看到,在SQL改写之前,即使在c_nationkey和s_nationkey有索引,数据库优化器利用索引避免了全表扫描;但是由于过滤条件nation = 100没有下推至数据表进行提前过滤...而经过FPPD改写之后的执行计划,通过将条件nation = 100下推到UNION子查询的两个分支,可以通过索引快速定位数据,并应用条件过滤,使得后续的分组和排序运算的输入大大减少,整体的执行时间也降低到...经过谓词下推重写优化,PawSQL可能基于重写后的SQL推荐最优索引,从而进一步提升查询的性能。 经过谓词下推重新优化,可能会触发其他类型的重写优化,譬如SATTC优化。

    13610

    SQL 教程:如何编写更佳的查询

    当然,从另一个角度来看,你也可以认为这类的查询可能会导致获取太多不一定满足查询目标的记录。...索引用于快速定位或查找数据,而不用在每次访问数据库表时必须搜索数据库中的每一行。索引可以用在数据库表中的一个或多个列来创建。 如果不使用数据库包含的索引,那么查询就会不可避免地需要更长时间运行。...在性能方面,顺序扫描显然不是最佳的执行计划,因为我们依然是在进行全表扫描。 然而,当表没法刚好放入内存时,这并不太糟糕:即使使用慢磁盘,顺序读取也会很快。 当讨论索引扫描时,我们会看到更多信息。...请注意,数据库的大小不仅会随着更多的数据存储在表中而增长,而且存在于数据库中的索引也会对大小增长起作用。...一旦构建了哈希表,就会扫描较大的表,并通过查看哈希表来查找较小表中的相关行。

    1.7K40

    索引与PostgreSQL新手

    因此,您需要添加自定义索引以使其高效。但是,在每个查询的基础上添加自定义索引并不是一种非常可扩展的方法。您可能会发现自己有多个冗余索引,这些索引会减慢写入操作。...它创建了一个不区分大小写的列,可以在不创建自定义索引的情况下进行高效搜索。...获得所需结果的一种简单方法是编写两个查询。第一个将获取已排序的非空值。如果结果不满足LIMIT,则另一个查询会获取剩余的带有NULL值的行。...,添加正确的索引可以显着提高查询执行时间。...但是,过度使用索引会大大增加数据库的大小并增加维护内存的使用。此外,必须在每次写入操作时更新索引。所以限制它们的数量和范围通常是一个好方法。 您的数据库可能有一些所谓的(我认为)“NULL 索引”。

    1.3K20

    百万数据分页查询优化方案

    分页问题 分页列表查询是项目中的热点需求,这种需求的特点是:字段多、数据量大、访问频繁、使用率高的特点,这个功能是给用户最直观的展示系统的信息,针对于多、大、频、热这几个特点,会引申出一个问题:列表展示的数据可能是来自于不同的数据维度...实际的业务场景下,可能会关联N张表,而且线上服务器的压力会比单机开发环境更重,因此实际接口响应时间会更长。...问题原因 回表:查询频率高的字段会建立索引,但是并不是所有的查询字段都会在索引上,无法命中索引的字段则需要回表,回表是IO操作,因为需要根据索引查找到数据行后,再根据数据行的主键或唯一索引去聚簇索引中查找具体的数据行...查询规则:limit 19999900,10并不是从第19999900行开始扫描,使用explain查看执行计划: 解决方案 当查询的字段都被索引覆盖时,可无需回表,那么我们可以先查询出主键id,再根据主键...因为主键id是最快的索引:聚簇索引,通过id就能快速找到指定行。 查询方案一: 先查询出id,再根据id直接查询数据。

    36330

    5个容易忽视的PostgreSQL查询性能瓶颈

    因此,您需要添加自定义索引以使其高效。但是,在每个查询的基础上添加自定义索引并不是一种非常可扩展的方法。您可能会发现自己有多个冗余索引,这些索引会减慢写入操作。...它创建了一个不区分大小写的列,可以在不创建自定义索引的情况下进行高效搜索。...获得所需结果的一种简单方法是编写两个查询。第一个将获取已排序的非空值。如果结果不满足LIMIT,则另一个查询会获取剩余的带有NULL值的行。...,添加正确的索引可以显着提高查询执行时间。...但是,过度使用索引会大大增加数据库的大小并增加维护内存的使用。此外,必须在每次写入操作时更新索引。所以限制它们的数量和范围通常是一个好方法。 您的数据库可能有一些所谓的(我认为)“NULL 索引”。

    3.6K92

    干货 | 基于ClickHouse的复杂查询实现与优化

    各个模块预定接口,减少彼此的依赖与耦合。即使模块发生变动或内部逻辑调整,也不会影响其他模块。其次,对模块采用插件架构,允许模块按照灵活配置支持不同的策略。这样便能够根据不同业务场景实现不同的策略。...如果 runtime filter 的列(join column)构建了索引(主键、skip index…),是需要重新生成 pipeline 的。...因为命中索引后,可能会减少数据的读取,pipeline 并行度和对应数据的处理 range 都可能发生变化。...这样即使 runtime filter 下发超时了,查询片段已经开始执行,只要查询片段没有执行完,之后的数据仍然可以进行过滤。...这里不谈论引擎执行通用的优化,比如更好的索引或者算子的优化,主要是跟复杂查询模式有关。

    3K20

    如何加快MySQL模糊匹配查询

    有时我会看到条件如下的模式匹配查询:“其中的字段名像'%something%'”。 MySQL不能为这些查询使用到索引,这意味着它必须每次都进行一次全表扫描。...Trigram表 我创建了这样的表格: ? 我们可以看到,有一个名为“trigram”的索引。 计划是为每个电子邮件地址创建一个trigram。 我写了以下触发器: ?...现在你可以喝一杯啤酒,因为这是你应得的。 选择性 ? 还有一些部分也会导致很多读数,但现在我们正在使用更长的模式: ? 使用六个以上的字符为我们提供了更好的选择性。 表统计 ?...优点 找到一个email地址将会更快,并需要更少的读取。 用户会更满意。 结论 如果MySQL中没有内置的解决方案或索引可以帮助或解决您的问题,请不要放弃。...很多时候,只需稍作修改,您就可以创建自己的索引表或使用其他技巧。 在这种特殊情况下,如果您愿意牺牲一些额外的磁盘空间,您可以使用正确的方法加快查询速度。

    3.7K50

    【黑魔法】Covering Indexes、STRAIGHT_JOIN

    自从看过耗子哥(左耳朵耗子)的博客,都会给对相应专题有兴趣的小伙伴列出几篇拓展文章,我觉得这种方式还是非常不错,所以这篇文章我也会列出几篇扩展的文章,供想更深入思考的小伙伴查阅。...可能有人会认为这两个用法会比较冷门,但是在跨系统调用api的过程中,表的数据量比较大时,sql查询性能太差,会导致接口响应超时,就会对相应的业务产生非常大的影响。...我们来分析下上面sql的执行计划:因为给“column3”建了索引,就会快速根据这个索引查询到符合条件的结果;然后再去这些符合条件的结果里查找所需的column1、column2字段;请注意,整个过程出现了两次查询...,一次是查询索引,另一次查询结果的所需字段。...明明Table1表的FilterID字段建了索引啊,Table1和Table2的CommonID也建了索引啊。通过explain来分析,你会发现执行计划中表的执行顺序是Table2->Table1。

    51620
    领券