mysql执行计划

1 背景 1 1.1 MVCC：Snapshot Read vs Current Read 2 1.2 Cluster Index：聚簇索引 3 1.3 2PL：Two-Phase Locking 3 1.4 Isolation Level 4 2 一条简单SQL的加锁实现分析 5 2.1 组合一：id主键+RC 6 2.2 组合二：id唯一索引+RC 6 2.3 组合三：id非唯一索引+RC 7 2.4 组合四：id无索引+RC 8 2.5 组合五：id主键+RR 9 2.6 组合六：id唯一索引+RR 9 2.7 组合七：id非唯一索引+RR 9 2.8 组合八：id无索引+RR 11 2.9 组合九：Serializable 12 3 一条复杂的SQL 12 4 死锁原理与分析 14 5 总结 16 背景 MySQL/InnoDB的加锁分析，一直是一个比较困难的话题。我在工作过程中，经常会有同事咨询这方面的问题。同时，微博上也经常会收到MySQL锁相关的私信，让我帮助解决一些死锁的问题。本文，准备就MySQL/InnoDB的加锁问题，展开较为深入的分析与讨论，主要是介绍一种思路，运用此思路，拿到任何一条SQL语句，都能完整的分析出这条语句会加什么锁？会有什么样的使用风险？甚至是分析线上的一个死锁场景，了解死锁产生的原因。 注： MySQL是一个支持插件式存储引擎的数据库系统

有关于MySQL的高级部分笔记 这是一篇关于 MySQL 高级部分的笔记主要是，sql优化以及mysql锁的相关内容，以及主从配置等内容等比较基础的优化 一、逻辑架构部分 逻辑架构 逻辑架构介绍图如下 　　　　　　 连接层：最上层是一些客户端和连接服务，包含本地的sock通讯大多时基于客户端/服务端工具实现的类似于tcp/ip的通讯 服务层：完成大多数的核心服务的功能，如，SQL接口，并完成缓存的查询SQL的分析和优化以及部分内置函数的执行，所有款存储引擎的功能 引擎层：存储引擎真正的负责了MySQL中的数据的存储和提取，服务器通过api与存储引擎进行通讯，常用的有MyISAM和InnoDB 存储层：数据存储在裸设备上，并完成与存储引擎的交互 优化主要是只使SQL的解析格式符合优化器的优化格式 存储引擎 查看mysql的存储引擎命令 # 看你的mysql提供了生么存储引擎show engines;# 看当前默认的存储引擎show variables like '%storage_engine%'; MyISAM与InnoDB的对比如下表 对比项 MyISAM InnoDB 主外键 不支持 支持 事务 不支持 支持 行表锁 表锁，即使操作一条记录也会锁住整个表， 不适合高并发的操作 行锁，操作时只锁某一行，不对其他的行有影响， 适合高并发的操作 缓存 只缓存索引不缓存真实数据

一、EXPLAIN 做MySQL优化，我们要善用EXPLAIN查看SQL执行计划。 下面来个简单的示例，标注（1、2、3、4、5）我们要重点关注的数据： type列，连接类型。一个好的SQL语句至少要达到range级别。杜绝出现all级别。 key列，使用到的索引名。如果没有选择索引，值是NULL。可以采取强制索引方式 key_len列，索引长度。 rows列，扫描行数。该值是个预估值。 extra列，详细说明。注意，常见的不太友好的值，如下：Using filesort，Using temporary。 二、SQL 语句中 IN 包含的值不应过多 MySQL对于IN做了相应的优化，即将IN中的常量全部存储在一个数组里面，而且这个数组是排好序的。但是如果数值较多，产生的消耗也是比较大的。再例如：select id from t where num in(1,2,3) 对于连续的数值，能用between就不要用in了；再或者使用连接来替换。 三、SELECT语句务必指明字段名称 SELECT*增加很多不必要的消耗（CPU、IO、内存、网络带宽）；增加了使用覆盖索引的可能性；当表结构发生改变时，前断也需要更新。所以要求直接在select后面接上字段名。 四、当只需要一条数据的时候，使用limit 1 这是为了使EXPLAIN中type列达到const类型 五、如果排序字段没有用到索引

在日常工作中，我们会有时会开慢查询去记录一些执行时间比较久的SQL语句，找出这些SQL语句并不意味着完事了，些时我们常常用到explain这个命令来查看一个这些SQL语句的执行计划，查看该SQL语句有没有使用上了索引，有没有做全表扫描，这都可以通过explain命令来查看。所以我们深入了解MySQL的基于开销的优化器，还可以获得很多可能被优化器考虑到的访问策略的细节，以及当运行SQL语句时哪种策略预计会被优化器采用。 -- 实际SQL，查找用户名为Jefabc的员工 select * from emp where name = 'Jefabc'; -- 查看SQL是否使用索引，前面加上explain即可 explain select * from emp where name = 'Jefabc'; expain出来的信息有10列，分别是id、select_type、table、type、possible_keys、key、key_len、ref、rows、Extra 概要描述： id:选择标识符 select_type:表示查询的类型。 table:输出结果集的表 partitions:匹配的分区 type:表示表的连接类型 possible_keys:表示查询时，可能使用的索引 key:表示实际使用的索引 key_len:索引字段的长度 ref:列与索引的比较 rows

mysql使用utf8mb4经验吐血总结 1. utf8 与 utf8mb4 异同 先看 官方手册 https://dev.mysql.com/doc/refman/5.6/en/charset-unicode-utf8mb4.html 的说明： The character set named utf8 uses a maximum of three bytes per character and contains only BMP characters. The utf8mb4 character set uses a maximum of four bytes per character supports supplementary characters: - For a BMP character, utf8 and utf8mb4 have identical storage characteristics: same code values, same encoding, same length. - For a supplementary character, utf8 cannot store the character at all, whereas utf8mb4 requires four bytes to store it. Because utf8

SQL提示（SQL HINT）是优化数据库的一种重要手段，简单来说就是在SQL语句中加入一些人为的提示来达到优化操作的目的。 下面是一个使用SQL提示的例子： SELECT SQL_BUFFER_RESULTS * FROM …… 这个语句将强制MySQL 生成一个临时结果集。只要临时结果集生成后，所有表上的锁定均被释放。这能在遇到锁问题时或者更长时间将结果传给客户端时有所帮助，因为可以尽快释放锁资源。 下面是一些在MySQL中常用的SQL提示。 USE INDEX 在查询语句中表名的后面，添加USE INDEX 来提供希望MySQL 去参考的索引列表，就可以让MySQL 不在考虑其他可用的索引。 mysql> show index from rental; +--------+------------+---------------------+--------------+--------------+-----------+-------------+----------+--------+------+------------+---------+---------------+ | Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part

常见MySQL错误用法有哪些？小白怎么学Web前端？无论是前端开发还是后台应用，都需要掌握数据库相关的知识，而MySQL是企业常用的数据库之一。对于一个Web前端小白来说，在完成HTML+CSS的基础学习后，他们还需要学习MySQL相关操作，下面列举几种比较常见的MySQL错误用法，希望大家能够引以为鉴。 1、隐式转换 SQL语句中查询变量和字段定义类型不匹配是另一个常见的错误。比如下面的语句： mysql> explain extended SELECT * > FROM my_balance b > WHERE b.bpn = 14000000123 > AND b.isverified IS NULL ; mysql> show warnings; | Warning | 1739 | Cannot use ref access on index 'bpn' due to type or collation conversion on field 'bpn' 其中字段bpn的定义为varchar(20)，MySQL的策略是将字符串转换为数字之后再比较。函数作用于表字段，索引失效。 上述情况可能是应用程序框架自动填入的参数，而不是程序员的原意。现在应用框架很多很繁杂，使用方便的同时也小心它可能给自己挖坑。 2、混合排序 MySQL不能利用索引进行混合排序，但在某些场景

1 数据库拆分过程及挑战 互联网当下的数据库拆分过程基本遵循的顺序是：垂直拆分、读写分离、分库分表(水平拆分)。每个拆分过程都能解决业务上的一些问题，但同时也面临了一些挑战。 1.1 垂直拆分 对于一个刚上线的互联网项目来说，由于前期活跃用户数量并不多，并发量也相对较小，所以此时企业一般都会选择将所有数据存放在一个数据库 中进行访问操作。举例来说，对于一个电商系统，其用户模块和产品模块的表刚开始都是位于一个库中。 其中：user、user_account表属于用户模块，product_category、product表属于产品模块。 刚开始，可能公司的技术团队规模比较小，所有的数据都位于一个库中。随着公司业务的发展，技术团队人员也得到了扩张，划分为不同的技术小组，不同的小组负责不同的业务模块。例如A小组负责用户模块，B小组负责产品模块。此时数据库也迎来了第一次拆分：垂直拆分。 这里的垂直拆分，指的是将一个包含了很多表的数据库，根据表的功能的不同，拆分为多个小的数据库，每个库包含部分表。下图演示将上面提到的db_eshop库，拆分为db_user库和db_product库。 通常来说，垂直拆分，都是根据业务来对一个库中的表进行拆分的。关于垂直拆分，还有另一种说法，将一个包含了很多字段的大表拆分为多个小表，每个表包含部分字段，这种情况在实际开发中基本很少遇到。

MySQL四层分层：（自上往下执行） 连接层：提供预客户端连接的服务。 服务层： 1.提供各种用户使用的接口 2.提供各种sql优化器（mysql如果发现你自己的sql写的太烂，会自动帮你优化） 引擎层： INNODB：事务优先 （ 适合高并发操作，使用的是行锁） MYISAM: 性能有限 （使用的是表锁） 存储层： 存储数据 查询数据库的引擎： SHOW VARIABLES LIKE '%storage_engine%' 查询数据库支持的引擎 : SHOW engines 为什么要SQL优化原因： 性能低，执行事件太长，等待时间太长，sql语句欠佳（连接查询），索引失效，服务器参数设置不合理 一般SQL编写过程 select ... distinct ... from ... join on ... where ... group by ... having ... order SQL的解析过程 from ... on ... join ... where ... group by ... having ... select ... distinct ... order sql如何进行优化，主要是索引的 优化 索引： 相当于书的目录（排好序，加快速度） 索引： index是帮助mysql高效获取数据的数据结构。索引是数据结构（b+） 索引的弊端： 1.索引本身很大，可以存放内存

一、 MySQL 中的执行计划 1 MySQL 执行计划 在 MySQL 中可以通过 explain 关键字模拟优化器,执行 SQL 语句，从而知道 MySQL 是 如何处理 SQL 语句的。 2 MySQL 整个查询执行过程 • 客户端向 MySQL 服务器发送一条查询请求 • 服务器首先检查查询缓存，如果命中缓存，则立刻返回存储在缓存中的结果。否则进入下一阶段 • 服务器进行 SQL 解析、预处理、再由优化器生成对应的执行计划 • MySQL 根据执行计划，调用存储引擎的 API 来执行查询 • 将结果返回给客户端，同时缓存查询结果 3 启动执行计划 EXPLAIN SELECT 投影列 FROM 表名 WHERE 条件 4 EXPLAIN 列的解释 4.1ID 查询执行顺序： id 值相同时表示从上向下执行 id 值相同被视为一组 如果是子查询，id 值会递增，id 值越高，优先级越高 4.2select_type simple: 表示查询中不包含子查询或者 union primary: 当查询中包含任何复杂的子部分，最外层的查询被标记成 primary derived: 在 from 的列表中包含的子查询被标记成 derived subquery: 在 select 或 where 列表中包含了子查询，则子查询被标记成 subquery union: 两个 select