在整个计算机运行系统里，Cpu，内存，和磁盘主要的性能瓶颈是卡在了读取数据中，Mysql索引的优化主要在减少磁盘I/O操作中，这篇博客中详细讲解了二叉树结构，以及BTree作为Mysql索引结构的根本原理，文章底部留下来几个常用的问题。
Select [distinct ] <字段名称> from 表 1 [ <join 类型> join 表 2 on <join 条件> ] where <where 条件> group by <字段>
在MySQL中，执行计划是优化器根据查询语句生成的一种重要的数据结构，它描述了如何通过组合底层操作实现查询的逻辑。当我们编写一条SQL语句时，MySQL会自动对其进行优化，并生成最优的执行计划以实现更快的查询速度。
MySQL 作为使用范围最广的开源关系型数据库，是每个后端开发人员都绕不开的一道坎。我在上一篇文章中也写了关于 MySQL 中的 MVCC 的细节及各个隔离级别如何使用 MVCC，有兴趣的可以查看。
Mysql中事务的隔离级别分为四大等级：读未提交（READ UNCOMMITTED）、读提交 （READ COMMITTED）、可重复读 （REPEATABLE READ）、串行化 （SERIALIZABLE）。
前段时间笔者开发某个项目遇到了MySQL性能问题，每张表的数据量都在五千万以上，个别表数据量甚至在一个亿以上，在开发的过程中遇到了非常多的数据库性能优化难点，笔者在开发过程中查询了很多资料，很多查询语句也在优化过程中取得了比较好的效果。笔者也将开发过程中遇到的sql优化问题总结为文章，以便日后回顾。这篇文章主要讲解mysql执行联结运算的原理。为了避免泄露公司业务及数据，在文章中涉及的sql语句都和公司业务无关。
实践中，MySQL的优化主要涉及SQL语句及索引的优化、数据表结构的优化、系统配置的优化和硬件的优化四个方面，如下图所示：
《MySQL性能调优，这个工具最有用》留了一个尾巴： select id,name where name='shenjian' select id,name,sex where name='shenjian' 多查询了一个属性，为何检索过程完全不同？ 什么是回表查询？ 什么是索引覆盖？ 如何实现索引覆盖？ 哪些场景，可以利用索引覆盖来优化SQL？ 这些，这是今天要分享的内容。 画外音：本文试验基于MySQL5.6-InnoDB。 一、什么是回表查询？ 这先要从InnoDB的索引实现说起，InnoDB有两大类
虽然使用Explain不能够马上调优我们的SQL，它也不能给予我们一些调整建议，但是它能够让我们了解MySQL 优化器是如何执行SQL 语句的
当我们使用如上所述的语法的时候，这两种方式在事务(Transaction) 进行当中SELECT 到同一个数据表时，都必须等待其它事务数据被提交(Commit)后才会执行。
正式讲 ICP 之前了，我们先将相关的概念捋一捋，知道的就当回顾，不知道的就当了解了，这有助于对 ICP 的理解
索引是帮助MySQL高效获取数据的数据结构。索引内部存在一个键值和对应数据的物理地址，当数据很多的时候，索引文件会很大，所以一般以文件的形式存储于磁盘中，后缀名为.myi。
最近学习极客时间的MySQL45讲，补充下对于MySQL方面的知识，也在这里把自己之前的疑惑问题记录下来，从中寻找答案。由于InnoDB为常用引擎，以下分期默认都是InnoDB场景。
前几天有粉丝和我聊到他找工作面试大厂时被问的问题，因为现在疫情期间，找工作也特别难找。他说面试的题目也比较难，都偏向于一两年的工作经验的面试题。
Explain查看查询计划主要包含如下信息列：查询id、查询类型、查询表、扫描访问类型、查询可能选用的索引、查询实际使用索引、mysql决定使用索引长度、ref 显示哪个字段或常数与key一起被使用、估算扫描行数、额外重要信息。--重点关注加粗部分。
索引在MySQL中是用来提高数据检索速度的数据结构。它们帮助MySQL更快地找到和访问表中的特定信息。索引的工作方式类似于书籍的索引：而不是逐页搜索书籍以找到所需的信息，您可以在索引中查找一个条目，该条目会告诉您在哪里可以找到所需的信息。在MySQL中，B树（特别是InnoDB存储引擎使用的B+树）是索引的常用数据结构。
这一篇文章分享mysql的面试知识，涵盖点比较多。下面我们来从总体到局部来看完mysql相关的面试知识。预告下一篇是网络面试知识，用图解的方式呈现给大家。希望大家多多支持，点赞，转发，在看 三连。
当MySQL使用一个索引来检索表中的行时，可以使用ICP作为一种优化方案。不使用ICP时，存储引擎通过索引检索基础表中的行并将符合WHERE条件中的行返回给客户端。启用ICP后，如果只需要通过索引中的列就能够评估行是否符合WHERE中的一部分条件，MySQL将这部分WHERE条件下推到存储引擎中，然后存储引擎评估使用索引条目来评估下推的索引条件，并只从表中读取符合条件的行。ICP可以减少存储引擎访问基础表的次数以及MySQL访问存储引擎的次数。
上篇文章说了，mysql5.6.6版本之前数据默认在系统表空间，之后默认在独立表空间，innodb因为索引和数据在一个b+树，所以两个文件，一个文件结构，一个存数据，myISAM则是三个文件。一个聚簇索引有两个段，叶子段和非叶子段，一个段有他专属的区，数据刚开始存在碎片区，不属于任何段，直属表空间。
在InnoDB中，锁可以分为两种级别，一种是共享锁（S锁），另一种是排他锁（X锁）。
SELECT class_no FROM student WHERE name = 'lcy' AND age > 18 GROUP BY class_no
最近公司项目添加新功能，上线后发现有些功能的列表查询时间很久。原因是新功能用到旧功能的接口，而这些旧接口的 SQL 查询语句关联5,6张表且编写不够规范，导致 MySQL 在执行 SQL 语句时索引失效，进行全表扫描。原本负责优化的同事有事请假回家，因此优化查询数据的问题落在笔者手中。笔者在查阅网上 SQL 优化的资料后成功解决了问题，在此从==全局角度==记录和总结 MySQL 查询优化相关技巧。
强烈推介IDEA2020.2破解激活，IntelliJ IDEA 注册码，2020.2 IDEA 激活码
前一段时间好兄弟找工作，面试 Java 资深研发工程师岗位，接到了不少大厂的面试邀请，有顺利接到 offer 的，也有半道儿面试被卡掉的。但最想去的企业却因为 MySQL表存储引擎 InnoDB ，与 offer 失之交臂。
这样写看起来很正常，但实际在数据量大了之后，使用起来开始出现问题，越来越慢，慢到不可接受，甚至影响其他的读写操作。
EXPLAIN SELECT * from user_info WHEREid = 1;
EXPLAIN 工具能用于获取查询执行计划，即分析 MySQL 如何执行一个 SQL 语句。我们可以通过使用EXPLAIN 去模拟优化器执行 SQL 语句，从而分析 SQL 语句有没有使用索引、是否采用全表扫描方式、判断能否更进一步优化等。我们可以根据EXPLAIN 输出的数据来分析如何优化查询语句，提升查询语句的性能瓶颈。
今天，数据库的操作越来越成为整个应用的性能瓶颈了，这点对于Web应用尤其明显。关于数据库的性能，这并不只是DBA才需要担心的事，而这更是我们程序员需要去关注的事情，希望文章的这些优化技巧对你有用。
要想使python可以操作mysql 就需要MySQL-python驱动，它是python 操作mysql必不可少的模块。下载地址：https://pypi.python.org/pypi/MySQL-python/，可以根据不同的平台下载不同的版本。这里以Windows平台为例，资源地址是：https://pypi.python.org/packages/27/06/596ae3afeefc0cda5840036c42920222cb8136c101ec0f453f2e36df12a0/MySQL-python-1.2.5.win32-py2.7.exe#md5=6f43f42516ea26e79cfb100af69a925e；Linux平台需下载源码zip包，下载MySQL-python-1.2.5.zip 文件之后直接解压。进入MySQL-python-1.2.5目录:
我们说到事务，就得说到事务的ACID特性，为什么需要隔离性呢？因为事务要能够允许并发执行，并发执行为了同时保证数据的安全性，一致性和并发的效率，就需要设置事务的隔离级别
MySQL支持多种数据存储引擎，其中最常见的是MyISAM和InnoDB引擎。可以通过使用"show engines"命令查看MySQL支持的存储引擎。
例如：select * from goods where id = 1 for update;
上篇文章MySQL的优化利器：索引条件下推，千万数据下性能提升273%🚀，我们说到MySQL中server层与存储引擎层的交互、索引、回表、ICP等知识（有不理解的概念可以看上篇文章哈~）
【1】Read Uncommitted（读取未提交内容）：出现脏读，也就是可能读取到其他会话中未提交事务修改的数据。 【2】Read Committed（读取已提交内容）：不可重复读，只能读取到已经提交的数据。Oracle 等数据库默认的隔离级别。 【3】Repeatable Read（可重复读）：出现幻读。在同一个事务内的查询都和事务开始时刻一致。InnoDB默认级别。 【4】Serializable（串行读）：完全串行化的读，每次读都需要获得表级共享锁，读写相互都会阻塞。
建表sql大家也不用扣细节，只需要知道id是主键，并且在user_name建了个非主键索引就够了，其他都不重要。
MySQL的査询优化器会通过两个API来了解存储引擎的索引值的分布信息,以决定如何使用索引。第一个API是 records_in_range()，通过向存储引擎传入两个边界值获取在这个范围大概有多少条记录。对于某些存储引擎，该接口返回精确值，例如MyISAM；但对于另一些存储引擎则是一个估算值，例如 InnoDB。 第二个API是info()，该接口返回各种类型的数据，包括索引的基数(每个键值有多少条记录)。 如果存储引擎向优化器提供的扫描行数信息是不准确的数据，或者执行计划本身太复杂以致无法准确地获取各个阶段匹配的行数，那么优化器会使用索引统计信息来估算扫描行数。 MySQL优化器使用的是基于成本的模型，而衡量成本的主要指标就是一个查询需要扫描多少行。如果表没有统计信息，或者统计信息不准确，优化器就很有可能做出错误的决定。可以通过运行ANALYZE TABLE来重新生成统计信息解决这个问题。 每种存储引擎实现索引统计信息的方式不同，所以需要进行ANALYZE TABLE的频率也因不同的引擎而不同，每次运行的成本也不同：
如果一个索引包含(或覆盖)所有需要查询的字段的值，称为‘覆盖索引’。即只需扫描索引而无须回表。 只扫描索引而无需回表的优点： 1.索引条目通常远小于数据行大小，只需要读取索引，则mysql会极大地减少数据访问量。 2.因为索引是按照列值顺序存储的，所以对于IO密集的范围查找会比随机从磁盘读取每一行数据的IO少很多。 3.一些存储引擎如myisam在内存中只缓存索引，数据则依赖于操作系统来缓存，因此要访问数据需要一次系统调用 4.innodb的聚簇索引，覆盖索引对innodb表特别有用。(innodb的二级索引在叶子节点中保存了行的主键值，所以如果二级主键能够覆盖查询，则可以避免对主键索引的二次查询)
SS可以兼容的，XS、SX、XX之间是互斥的，即读锁之间可以共享，读写和写写之间是不兼容的
左边子节点的数据小于父节点数据，右边子节点的数据大于父节点数据。如果col2是索引，查找索引为89的行元素，那么只需要查找两次，就可以获取到行元素所在的磁盘指针地址。
客户端发往MySQL的一条条SQL语句，实际上都可以理解成一个个单独的事务（一条sql语句默认就是一个事务）。而事务是基于数据库连接的，每个数据库连接在MySQL中，又会用一条工作线程来维护，也意味着一个事务的执行，本质上就是一条工作线程在执行，当出现多个事务同时执行时，这种情况则被称之为并发事务，所谓的并发事务也就是指多条线程并发执行。
含有子查询的时候，表明各语句执行的先后顺序，如果数字相同，则按照先后顺序执行，如果为 null，则代表是结果集，不需要查询。
时间类型：MySQL字段的时间类型该如何选择？千万数据下性能提升10%~30%🚀
在MySQL中，我们可以通过EXPLAIN命令获取MySQL如何执行SELECT语句的信息，包括在SELECT语句执行过程中表如何连接和连接的顺序。
索引合并是MySQL查询优化器在处理复杂查询条件时使用的一种技术。简单来说，当WHERE子句中有多个条件，并且每个条件都可以利用不同的索引时，优化器会考虑将这些索引的扫描结果合并，从而得到最终的结果集。
优化SQL，是DBA常见的工作之一。如何高效、快速地优化一条语句，是每个DBA经常要面对的一个问题。在日常的优化工作中，我发现有很多操作是在优化过程中必不可少的步骤。然而这些步骤重复性的执行，又会耗费DBA很多精力。于是萌发了自己编写小工具，提高优化效率的想法。
良好的schema设计原则是普遍适用的，但是MySQL有他自己的实现细节要注意，概况来讲，尽可能保持任何东西小而简单总是好的。
前面说了mysql会吧一些冗余的sql语句查询优化重写，比如多于的括号，比如有的外连接其实跟内连接类似，可以优化查询表的顺序。子查询又分为相关和不相关子查询，如果子查询过滤条件里有外层查询的参数，则是相关子查询，反之则是不相关子查询。Any函数就代表只要有一个就行，最小的，all代表必须所有的都满足这个条件，所以必须最大的也满足。当我们判断子查询里是否存在的时候，则用exists判断，有则返回true。
插件式存储引擎是MySQL最重要的特性之一 优化表碎片：OPTIMIZE TABLE table_name 存储过程和函数是事先经过编译并存储在数据库中的一段SQL语句的集合，可以减少开发人员很多工作；
MySQL锁系列文章已经鸽了挺久了，最近赶紧挤了挤时间，和大家聊一聊MySQL的锁。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
