mysql执行计划

转载 http://blog.csdn.net/opensure/article/details/46227695 MySQL 加锁处理分析 标签： Database Deadlock Lock MySQL 2015-05-29 11:14 1101人阅读 评论 (0) 收藏 举报 分类： mysql（1） 目录 (?) [+] 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的加锁分析，一直是一个比较困难的话题。我在工作过程中，经常会有同事咨询这方面的问题。同时

链接地址： http://hedengcheng.com/?p=771 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 加锁处理分析 http://hedengcheng.com/?p=771 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语句，都能完整的分析出这条语句会加什么锁

MVCC：Snapshot Read vs Current Read MySQL InnoDB存储引擎，实现的是基于多版本的并发控制协议——MVCC ( Multi-Version Concurrency Control ) (注：与MVCC相对的，是基于锁的并发控制，Lock-Based Concurrency Control)。MVCC最大的好处，相信也是耳熟能详：读不加锁，读写不冲突。在读多写少的OLTP应用中，读写不冲突是非常重要的，极大的增加了系统的并发性能，这也是为什么现阶段，几乎所有的RDBMS，都支持了MVCC。 在MVCC并发控制中，读操作可以分成两类：快照读 (snapshot read)与当前读 (current read)。快照读，读取的是记录的可见版本 (有可能是历史版本)，不用加锁。当前读，读取的是记录的最新版本，并且，当前读返回的记录，都会加上锁，保证其他事务不会再并发修改这条记录。 Innodb锁问题 InnoDB与MyISAM的最大不同有两点：一是支持事务（TRANSACTION）；二是采用了行级锁。行级锁与表级锁本来就有许多不同之处，另外，事务的引入也带来了一些新问题。下面我们先介绍一点背景知识，然后详细讨论InnoDB的锁问题。 InnoDB实现了以下两种类型的行锁。 l 共享锁（S）：允许一个事务去读一行，阻止其他事务获得相同数据集的排他锁。

定义:视图是从一个或几个基本表导出的表，它与基本表不同，是一个虚表。 作用： 1.简化操作,不用进行多表查询。 2.当不同种类的用用户共享同一个数据库时,非常灵活,(用户以不同的 方式看待同一数据. 3.视图对重构数据库提供了一定程度的逻辑独立性。 数据的逻辑独立性是指:如增加新的关系或对原有的关系增加新的 字段,用户的应用程序不受影响. 例如：原有一个Student(Sno,Sname,Ssex,Sage,Sdept)这样一个表. 后来变动为:Sx(Sno,Sname,Sage)和SY（Sno,Ssex,Sdept) 两个表。 这时候原表Student为SX和SY表自然连接的结果。 那么如果我们一开始建立了一个试图： create view Student(Sno,Sname,Ssex,Sage,Sdept) as select SX.Sno,SX.Sname,SY.Ssex,SX,Sage,SY,Sdept from SX,SY where SX.Sno=SY.Sno; 尽管数据库的逻辑结构改变了，但是应用程序不必修改(因为这个这个 视图所定义的关系没有变啊）。 【注意:试图只能在一定程度上提供数据的逻辑独立,比如由于 视图的更新是有条件的,因此应用程序中修改数据的语句可能仍会 因为基本表构造的改变而改变. 4. 视图能够对机密数据提供安全保护 有了视图机制

二、优化细节： 1、参数优化 1.1 Max_connections （1）简介 Mysql的最大连接数，如果服务器的并发请求量比较大，可以调高这个值，当然这是要建立在机器能够支撑的情况下，因为如果连接数越来越多，mysql会为每个连接提供缓冲区，就会开销的越多的内存，所以需要适当的调整该值，不能随便去提高设值。 （2）判断依据 show variables like 'max_connections'; +-----------------+-------+ | Variable_name | Value | +-----------------+-------+ | max_connections | 151 | +-----------------+-------+ show status like 'Max_used_connections'; +----------------------+-------+ | Variable_name | Value | +----------------------+-------+ | Max_used_connections | 101 | +----------------------+-------+ 如果max_used_connections跟max_connections相同,那么就是max

MySQL 的逻辑架构图设计图 连接/线程处理： 管理客户端连接/会话[mysql threads] 解析器： 通过检查SQL查询中的每个字符来检查SQL语法，并 为每个SQL查询 生成 SQL_ID 。 此外，身份验证检查（用户凭据）将在此阶段发生。 优化程序： 根据存储引擎创建有效的查询执行计划。 它将重写一个查询。 示例：InnoDB具有共享缓冲区，因此优化器将从中获取预缓存的数据。 使用表统计信息优化器将为SQL查询生成执行计划。 授权检查（用户访问权限）将在此阶段发生。 元数据缓存： 缓存对象元数据信息和统计信息。 查询缓存： 来自内存的共享相同查询。如果在查询缓存中找到来自客户端的相同查询，则MySQL服务器从查询缓存中检索结果，而不是再次解析和执行该查询。 它是会话的共享缓存，因此可以发送一个客户端生成的结果集以响应另一个客户端发出的相同查询。 查询缓存基于 SQL_ID .SELECT数据进入视图是使用查询缓存预缓存数据的最佳示例。 密钥缓存： 缓存表索引。在 MySQL 中密钥是索引（在oracle密钥是约束），如果索引大小小，那么它将缓存索引结构和数据叶。如果索引很大，那么它将只缓存索引结构。由MyISAM 使用存储引擎。 存储引擎： 管理物理数据（文件管理）和位置的MySQL组件。 存储引擎负责执行SQL语句并从数据文件中获取数据。 用作插件

索引的作用是什么 告诉存储引擎如何快速的查找所需要的数据，类似目录，可以快速定位到某个区域，而如果没有索引，只能一页一页翻找寻找需要的内容。在磁盘上表现就是要慢慢扫描查找。 Innodb支持的索引类型 Btree索引 自适应HASH索引 全文索引 空间索引 一般没特别说明，都是指Btree索引，结构如下图 -- 查询出2019年1月1号之后注册的男性会员昵称 EXPLAIN SELECT user_nick FROM imc_user WHERE sex=1 AND reg_time>'2019-01-01'; 输出 id select_type table partitions type possible_keys key key_len ref rows filtered Extra ------ ----------- -------- ---------- ------ ------------- ------ ------- ------ ------ -------- ------------- 1 SIMPLE imc_user (NULL) ALL idx_sex (NULL) (NULL) (NULL) 2530 3.33 Using where -- 筛选性 SELECT COUNT(DISTINCT sex) ,COUNT(DISTINCT DATE

触发器的特性 触发器的应用场景 查看触发器 删除触发器 创建触发器 关于触发器的进一步介绍 触发器的特性 需要MySQL 5 对触发器的支持是在MySQL 5中增加的 仅支持表 只有表才支持触发器，视图不支持（临时表也不支持）。 保持每个数据库的触发器名唯一 在MySQL 5中，触发器名必须在每个表中唯一，但不是在每个数据库中唯一。这表示同一数据库中的两个表可具有相同名字的触发器。这在其他每个数据库触发器名必须唯一的DBMS中是不允许的，而且以后的MySQL版本很可能会使命名规则更为严格。因此，现在最好是在数据库范围内使用唯一的触发器名。 触发器失败 如果BEFORE触发器失败，则MySQL将不执行请求的操作。此外，如果BEFORE触发器或语句本身失败，MySQL将不执行AFTER触发器（如果有的的话) BEFORE或AFTER 通常，将BEFORE用于数据验证和净化（目的是保证插入表中的数据确实是需要的数据) 触发器的应用场景 需要在某个表发生更改时自动处理。 例如: 每当增加一个顾客到某个数据库表时，都检查其电话号码格式是否正确，州的缩写是否为大写； 每当订购一个产品时，都从库存数量中减去订购的数量； 无论何时删除一行，都在某个存档表中保留一个副本。 触发器是MySQL响应以下任意语句而 自动执行的一条MySQL语句（或位于BEGIN和END语句之间的一组语 句）： 

最近遇见一个 MySQL 的慢查问题，于是排查了下，这里把相关的过程做个总结。 定位原因 我首先查看了 MySQL 的慢查询日志，发现有这样一条 query 耗时非常长（大概在 1 秒多），而且扫描的行数很大（10 多万条数据，差不多是全表了）： SELECT * FROM tgdemand_demand t1WHERE(t1.id IN(SELECT t2.demand_idFROM tgdemand_job t2WHERE (t2.state = 'working' AND t2.wangwang = 'abc'))ANDNOT (t1.state = 'needConfirm'))ORDER BY t1.create_date DESC 这个查询不是很复杂，首先执行一个子查询，取到任务的状态（state）是 ‘working’ 并且任务的关联人 （wangwang）是’abc’的所有需求 id（这个设计师进行中的任务对应的需求 id），然后再到主表 tgdemand_demand 中带入刚才的 id 集合，查询出需求状态（state）不是 ‘needConfirm’ 的所有需求，最后进行一个排序。 按道理子查询筛选出 id 后到主表过滤是直接使用到主键，应该是很快的啊。而且，我检查了子查询的 tgdemand_job 表的索引，where 中用到的查询条件都已经增加了索引