在MySQL 5.6之前，当查询使用到复合索引时，MySQL会先根据索引的最左前缀原则，在索引上查找到满足条件的记录的主键或行指针，然后再根据这些主键或行指针到数据表中查询完整的行记录。之后，MySQL再根据WHERE子句中的其他条件对这些行进行过滤。这种方式可能导致大量的数据行被检索出来，但实际上只有很少的行满足WHERE子句中的所有条件。
在《MySQL 常见语句加锁分析》一文中，我们详细讲解了 SQL 语句的加锁原理并具体分析了大部分的简单 SQL 语句，但是实际业务场景中 SQL 语句往往及其复杂，包含多个条件，此时就需要具体分析SQL 使用到的索引，并了解 where 条件的判断逻辑。
本文是在假定读者了解了直方图是什么，直方图如何进行添加维护的前提下，围绕直方图与索引的对比、何时应该添加直方图，及直方图如何帮助优化器选择更优的执行计划这几个方面来介绍直方图。 对直方图不太了解的小伙伴可参考GreatSQL社区的另一篇文章 4.直方图介绍和使用|MySQL索引学习
在MySQL数据库中，索引是提高查询性能的关键。为了进一步优化查询性能，MySQL引入了索引下推的概念。索引下推是指在使用索引进行查询时，将过滤条件下推到存储引擎层级进行处理，减少不必要的数据读取和传输，从而提高查询效率。
SELECT class_no FROM student WHERE name = 'lcy' AND age > 18 GROUP BY class_no
一 概念介绍 Index Condition Pushdown (ICP)是MySQL 5.6 版本中的新特性,是一种在存储引擎层使用索引过滤数据的一种优化方式。 a 当关闭ICP时,index 仅仅是data access 的一种访问方式，存储引擎通过索引回表获取的数据会传递到MySQL Server 层进行where条件过滤。 b 当打开ICP时,如果部分where条件能使用索引中的字段,MySQL Server 会把这部分下推到引擎层,可以利用index过滤的where条件在存储引擎层进行数据过滤,而非将所有通过index access的结果传递到MySQL server层进行where过滤. 优化效果:ICP能减少引擎层访问基表的次数和MySQL Server 访问存储引擎的次数,减少io次数，提高查询语句性能。 二 原理
背景 MySQL/InnoDB的加锁分析，一直是一个比较困难的话题。我在工作过程中，经常会有同事咨询这方面的问题。同时，微博上也经常会收到MySQL锁相关的私信，让我帮助解决一些死锁的问题。本文，准备就MySQL/InnoDB的加锁问题，展开较为深入的分析与讨论，主要是介绍一种思路，运用此思路，拿到任何一条SQL语句，都能完整的分析出这条语句会加什么锁？会有什么样的使用风险？甚至是分析线上的一个死锁场景，了解死锁产生的原因。 注：MySQL是一个支持插件式存储引擎的数据库系统。本文下面的所有介绍，都是基于I
索引条件下推，也叫索引下推，英文全称Index Condition Pushdown，简称ICP。
索引下推（INDEX CONDITION PUSHDOWN，简称 ICP）是 MySQL 5.6 发布后针对扫描二级索引的一项优化改进。总的来说是通过把索引过滤条件下推到存储引擎，来减少 MySQL 存储引擎访问基表的次数以及 MySQL 服务层访问存储引擎的次数。ICP 适用于 MYISAM 和 INNODB，本篇的内容只基于 INNODB。
视图在数据库中是非常普及的功能。但是长期以来，大多数互联网公司的《MySQL开发规范》中都有一条规范：在MySQL中禁止（或建议不要）使用视图。究其原因，主要是由于在MySQL中视图的查询性能不好，同时带来了管理维护上的高成本。 不过随着MySQL 8.0中派生条件下推特性的引入，尤其是最近GA的MySQL 8.0.29版本中对于包含union子句的派生条件下推优化，MySQL中视图查询的性能得到了质的提升。 《MySQL开发规范》已经过时了，DBA该考虑考虑将禁止使用视图的规定重新修订一下了。
MySQL数据库是许多Web应用程序的底层支持，而查询性能的优化是确保系统高效运行的关键。在MySQL中，EXPLAIN是一项强大的工具，可帮助开发者深入了解查询语句的执行计划，从而更好地优化查询性能。本文将详细解析MySQL的EXPLAIN关键字，以揭开查询执行计划的面纱。
神奇的 SQL 之 联表细节 → MySQL JOIN 的执行过程（一）中，我们讲到了 3 种联表算法：SNL、BNL 和 INL，了解了数据的查询方式是 one by one，联表方式也是 one by one ；并谈到了 ON 和 WHERE，对下图中所说的提出了质疑
含有子查询的时候，表明各语句执行的先后顺序，如果数字相同，则按照先后顺序执行，如果为 null，则代表是结果集，不需要查询。
随着业务不断迭代，系统中出现了较多的SQL慢查。慢查虽不致命，但会让商家感知到系统较慢，影响使用体验。在进行慢查优化过程中，我们积累了一些经验。本文将基于我们的实战经历，讲解工作中比较常见的慢查原因，以及如何去优化。
一条SQL，在数据库中是如何执行的呢？相信很多人都会对这个问题比较感兴趣。当然，要完整描述一条SQL在数据库中的生命周期，这是一个非常巨大的问题，涵盖了SQL的词法解析、语法解析、权限检查、查询优化、SQL执行等一系列的步骤，简短的篇幅是绝对无能为力的。因此，本文挑选了其中的部分内容，也是我一直都想写的一个内容，做重点介绍：
一条 SQL 在数据库中是如何执行的呢 ？相信很多人都会对这个问题比较感兴趣。但是，感兴趣归感兴趣，你得去追呀，还臆想着她主动到你怀里来 ？
在MySQL中，我们可以通过EXPLAIN命令获取MySQL如何执行SELECT语句的信息，包括在SELECT语句执行过程中表如何连接和连接的顺序。
上篇文章已经详细介绍 MySQL 组合索引的概念以及其适用场景，这篇主要介绍 MySQL 组合索引的不适用场景以及改造方案。
索引下推是从 MySQL5.6 开始引入一个特性，英文是 index condition pushdown，一般简称为 ICP，索引下推通过减少回表的次数，来提高数据库的查询效率。
前面说了mysql优化器访问数据库的方法有const，ref，ref_or_null，range，index，all。然后又分为条件全部是索引回表查询，和条件有非索引查询，则需要回表之后，在过滤。又有intersection合并索引和union并集索引，当两个单独二级索引查询，不是联合索引查询，可能会触发这两个索引查询，用and是intersection，用or是union查询，触发有两个注重点：
原文链接：http://www.toutiao.com/a6730869910135636494/
发现没有用到索引，type全是ALL，那么首先想到的就是建立一个索引，建立索引的字段当然是在where条件的字段。
正式讲 ICP 之前了，我们先将相关的概念捋一捋，知道的就当回顾，不知道的就当了解了，这有助于对 ICP 的理解
那这条语句呢？其实这其中包含太多知识点了。要回答这两个问题，首先需要了解一些知识。
不啰嗦，直接入正题。问题是这样的。请问下面的sql语句，要想加快查询速度，该怎么创建索引？以下，以mysql数据库为准。
局部索引等价于我们通常说的本地索引，与主表的数据结构保持一对一的关系。局部索引没有单独分区的概念，一般来讲，主表的分区方式决定局部索引的分区方式，也就是说假设主表有10个分区，那么对于每个分区来讲，都有一个对应的局部索引。
索引可以让查询锁定更少的行。如果你的查询从不访问那些不需要的行，那么就会锁定更少的行，从两个方面来看这对性能都有好处。
如果一个索引包含(或覆盖)所有需要查询的字段的值，称为‘覆盖索引’。即只需扫描索引而无须回表。 只扫描索引而无需回表的优点： 1.索引条目通常远小于数据行大小，只需要读取索引，则mysql会极大地减少数据访问量。 2.因为索引是按照列值顺序存储的，所以对于IO密集的范围查找会比随机从磁盘读取每一行数据的IO少很多。 3.一些存储引擎如myisam在内存中只缓存索引，数据则依赖于操作系统来缓存，因此要访问数据需要一次系统调用 4.innodb的聚簇索引，覆盖索引对innodb表特别有用。(innodb的二级索引在叶子节点中保存了行的主键值，所以如果二级主键能够覆盖查询，则可以避免对主键索引的二次查询)
我们知道，所谓表连接就是把各个表中的记录都取出来进行依次匹配，最后把匹配组合的记录一起发送给客户端。比如下面把t1表和t2表连接起来的过程如下图
通常大家都会根据查询的WHERE条件来创建合适的索引，不过这只是索引优化的一个方面。设计优秀的索引应该考虑到整个查询，而不单单是WHERE条件部分。索引确实是一种查找数据的高效方式，但是MySQL也可以使用索引来直接获取列的数据，这样就不再需要读取数据行。如果索引的叶子节点中已经包含要查询的数据，那么还有什么必要再回到表中查询呢？如果一个索引覆盖所有需要查询的字段的值，我们就称之为“覆盖索引”。
熟悉 MySQL 的同学一定都知道，MySQL 对于复杂条件查询的支持并不好。MySQL 最多使用一个条件涉及的索引来过滤，然后剩余的条件只能在遍历行过程中进行内存过滤。
在 MySQL 中，WHERE 子句和 HAVING 子句都有过滤的作用，它们有什么区别呢？
在关系型数据库中设计索引其实并不是复杂的事情，很多开发者都觉得设计索引能够提升数据库的性能，相关的知识一定非常复杂。 然而这种想法是不正确的，索引其实并不是一个多么高深莫测的东西，只要我们掌握一定的方
之前的文章中对于explain的数据结果中的字段已经进行了一部分介绍了，今天来说一说剩下的几个字段，为了防止忘记，先看看这个表结构：
熟悉 MySQL 的同学一定都知道，MySQL 对于复杂条件查询的支持并不好。MySQL 最多使用一个条件涉及的索引来过滤，然后剩余的条件只能在遍历行过程中进行内存过滤，对这个过程不了解的同学可以先行阅读一下《MySQL复杂where条件分析》。
MYSQL中索引是经常用来对数据库查询性能优化的方式，再MySQL中采用了B+树作为索引结构来减少磁盘IO次数去提高数据的检索性能。但是在某些场景下，由于查询语句设计不合理，或者对MySQL的理解不够深入。索引有可能会失效，变为全表扫描，这对于大数据量的查询是非常低效的。今天我们就来聊聊这些常见的失效场景。
一、前言 在MySQL中进行SQL优化的时候，经常会在一些情况下，对MySQL能否利用索引有一些迷惑。 譬如: MySQL 在遇到范围查询条件的时候就停止匹配了，那么到底是哪些范围条件？ MySQL 在LIKE进行模糊匹配的时候又是如何利用索引的呢？ MySQL 到底在怎么样的情况下能够利用索引进行排序？ 今天，我将会用一个模型，把这些问题都一一解答，让你对MySQL索引的使用不再畏惧 ---- 二、知识补充 key_len EXPLAIN执行计划中有一列 key_len 用于表示本次查询中，所选择的索引长
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
在MySQL中进行SQL优化的时候，经常会在一些情况下，对MySQL能否利用索引有一些迷惑。
一、前言 在MySQL中进行SQL优化的时候，经常会在一些情况下，对MySQL能否利用索引有一些迷惑。 譬如: MySQL 在遇到范围查询条件的时候就停止匹配了，那么到底是哪些范围条件？ MySQL 在LIKE进行模糊匹配的时候又是如何利用索引的呢？ MySQL 到底在怎么样的情况下能够利用索引进行排序？ 今天，我将会用一个模型，把这些问题都一一解答，让你对MySQL索引的使用不再畏惧 二、知识补充 key_len EXPLAIN执行计划中有一列 key_len 用于表示本次查询中，所选择的索引长度有多少字
在刚工作的时候，发现分页场景下，当offset变大，MySQL处理速度非常慢！具体sql如下：
在MySQL中进行SQL优化的时候，经常会在一些情况下，对MySQL能否利用索引有一些迷惑。例如:
MySQL 从 4.1 版本开始支持子查询，使用子查询可以进行 SELECT 语句的嵌套查询，即一个 SELECT 查询的结果作为另一个 SELECT 语句的条件。子查询可以一次性完成很多逻辑上需要多个步骤才能完成的操作 。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
