mysql执行计划

一、相关名词 |--表级锁（锁定整个表） |--页级锁（锁定一页） |--行级锁（锁定一行） |--共享锁（S锁，MyISAM 叫做读锁） |--排他锁（X锁，MyISAM 叫做写锁） |--悲观锁（抽象性，不真实存在这个锁） |--乐观锁（抽象性，不真实存在这个锁） 二、InnoDB与MyISAM Mysql 在5.5之前默认使用 MyISAM 存储引擎，之后使用 InnoDB 。查看当前存储引擎： show variables like '%storage_engine%'; MyISAM 操作数据都是使用的表锁，你更新一条记录就要锁整个表，导致性能较低，并发不高。当然同时它也不会存在死锁问题。 而 InnoDB 与 MyISAM 的最大不同有两点：一是 InnoDB 支持事务；二是 InnoDB 采用了行级锁。也就是你需要修改哪行，就可以只锁定哪行。 在 Mysql 中，行级锁并不是直接锁记录，而是锁索引。索引分为主键索引和非主键索引两种，如果一条sql 语句操作了主键索引，Mysql 就会锁定这条主键索引；如果一条语句操作了非主键索引，MySQL会先锁定该非主键索引，再锁定相关的主键索引。 InnoDB 行锁是通过给索引项加锁实现的，如果没有索引，InnoDB 会通过隐藏的聚簇索引来对记录加锁。也就是说：如果不通过索引条件检索数据，那么InnoDB将对表中所有数据加锁

一、MySQL还是个黑盒子 我们都知道，只要我们系统引入了 MySQL 驱动和连接池，就能从数据库连接池获取一个数据库连接，然后就可以执行增删改查的操作了。 可是我们并不知道 MySQL 里面是怎么执行的，例如我们执行了 insert 语句，只知道表里面多了一条数据，MySQL 是怎么插入的我们就不知道了。 二、解开 MySQL 这个黑盒子 1、一条工作线程： 举例： 我们都知道，在 Socket 编程里，ServerSocket 会有一条线程负责监听 Socket 发送过来的网络请求，并且负责从网络请求里读取请求数据，然后再进行处理 。 原理： 那么在 MySQL 里也是一样的道理，会有一条 工作线程 专门去监听 MySQL 数据库连接池里的网络请求，并且负责将请求中的 SQL 读取出来。 2、 SQL 接口： 上面说到 MySQL 的工作线程会从网络连接中读取 SQL。但是接下来是由谁继续执行呢？ 举例： 我们可以想象一下，在我们的 Web 系统里头，Tomcat 这个进程会接收客户端的网络请求，然后经过转发交给我们写的接口执行。 举例： 在 MySQL 里其实也一样，MySQL 就是一个数据库管理系统，上面提及到的工作线程会接收各个客户端的网络请求，然后经过转发交给内部的接口执行。 而这里的内部接口，叫 SQL 接口 ，它是 MySQL 内部里的一个组件。它是一套执行 SQL

原文： https://www.jb51.net/article/139113.htm MySQL的锁机制比较简单，其最显著的特点是不同的存储引擎支持不同的锁机制。比如，MyISAM和MEMORY存储引擎采用的是表级锁；BDB存储引擎采用的是页面锁，但也支持表级锁；InnoDB存储引擎既支持行级锁，也支持表级锁，但默认情况下采用行级锁。 MySQL这3种锁的特性可大致归纳如下： （1）表级锁 ：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低。 （2）行级锁 ：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。 （3）页面锁 ：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。 仅从锁的角度来说，表级锁更适合于以查询为主，只有少量按索引条件更新数据的应用，如Web应用；而行级锁则更适合于有大量按索引条件并发更新少量不同数据，同时又有并发查询的应用，如一些在线事务处理系统。 一、MyISAM表锁 1. 查询表级锁争用情况 show status like 'table%'; 如果table_locks_waited 的值比较高，则说明存在着比较严重的表级锁争用情况。 2. MySQL表级锁的锁模式 MySQL 的表级锁有两种模式：表共享读锁和表独占写锁。 当一个session对某个表加了读锁之后

优秀DBA的素质 1 、人品，不做某些事情 2 、严谨，运行命令前深思熟虑，三思而后行，即使是依据select 3 、细心，严格按照步骤一步一步执行，减少出错 4 、心态，遇到灾难，首先要稳住，不慌张，不要受到旁人的影响 5 、熟悉操作系统，Linux系统的工具和命令 6 、熟悉业务 ( 开发 )，编程语言 7 、熟悉行业 8 、喜欢数据库 • 什么是数据？ 数据是指对客观事件进行记录并可以鉴别的符号，是对客观事物的性质、状态以及相互关系等进行记载的物理符号或这些物理符号的组合。它是可识别的、抽象的符号。 • 什么是数据库管理系统？ 将大量的数据规范的管理在一起的软件 • 数据库管理系统种类 关系型和非关系型 • 关系型数据库的特点 　　– 二维表 　　– 典型产品 Oracle传统企业， MySQL是互联网企业 　　– 数据存取是通过SQL 　　– 最大特点，数据安全性方面强（ACID） • NoSQL：非关系型数据库（Not only SQL） 　　– 不是否定关系型数据库，做关系型数据库的的补充。 　　– 想做老大，先学会做老二。 RDBMS与NoSQL对比 • web1.0时代 　　企业提供内容，用户浏览，所以关系型数据库够用，并发并不高，所以不需要NoSQL。 • web2.0时代 　　核心是企业提供平台，用户参与提供内容。这时关系型数据库无法满足需求了。 • 2003

存储过程简介 SQL语句需要先编译然后执行，而存储过程（Stored Procedure）是一组为了完成特定功能的SQL语句集，经编译后存储在数据库中，用户通过指定存储过程的名字并给定参数（如果该存储过程带有参数）来调用执行它。 存储过程是可编程的函数，在数据库中创建并保存，可以由SQL语句和控制结构组成。当想要在不同的应用程序或平台上执行相同的函数，或者封装特定功能时，存储过程是非常有用的。数据库中的存储过程可以看做是对编程中面向对象方法的模拟，它允许控制数据的访问方式。 存储过程的优点： (1). 增强SQL语言的功能和灵活性 ：存储过程可以用控制语句编写，有很强的灵活性，可以完成复杂的判断和较复杂的运算。 (2). 标准组件式编程 ：存储过程被创建后，可以在程序中被多次调用，而不必重新编写该存储过程的SQL语句。而且数据库专业人员可以随时对存储过程进行修改，对应用程序源代码毫无影响。 (3). 较快的执行速度 ：如果某一操作包含大量的Transaction-SQL代码或分别被多次执行，那么存储过程要比批处理的执行速度快很多。因为存储过程是预编译的。在首次运行一个存储过程时查询，优化器对其进行分析优化，并且给出最终被存储在系统表中的执行计划。而批处理的Transaction-SQL语句在每次运行时都要进行编译和优化，速度相对要慢一些。 (4).减少网络流量

第十八章 全文本搜索 使用MySQL的全文本搜索功能进行高级的数据查询和选择。 18.1 理解全文本搜索 注 ：并非所有引擎都支持全文本搜索。两个最常用的引擎为 MyISAM 和 InnoDB ，前者支持全文本搜索，而后者不支持。 LIKE 关键字，利用通配操作符匹配文本（和部分文本）。使用LIKE，能够查找包含特殊值或部分值的行（不管这些值位于列内什么位置）。 正则表达式 ：使用正则表达式，可以编写查找所需行的非常复杂的匹配模式。 虽然这些搜索机制非常有用，但存在几个重要的限制。 性能——通配符和正则表达式匹配通常要求MySQL尝试匹配表中所有行（而且这些搜索极少使用表索引）。因此，由于被搜索行数不断增加，这些搜索可能非常耗时。 明确控制——使用通配符合正则表达式匹配，很难（而且并不总是能）明确地控制匹配什么和不匹配什么。例如，指定一个词必须匹配，而一个词仅在第一个词确实匹配的情况下才可以匹配或者才可以不匹配。 智能化的结果——虽然基于通配符和正则表达式的搜索提供了非常灵活的搜索，但它们都不能提供一种智能化的选择结果的方法。例如，一个特殊词的搜索将会返回包含该词的所有行，而不区分包含单个匹配的行和包含多个匹配的行（按照可能是更好的匹配来排列它们）。类似，一个特殊词的搜索将不会找出不包含该词但包含其他相关词的行。 所有这些限制以及更多限制都可以用全文本搜索来解决。在使用全文本搜索时

前言 要想优化SQL语句，首先得知道SQL语句有什么问题，哪里需要被优化。这样就需要一个SQL语句的监控与量度指标，本文讲述的 explain 和 show profile 就是这样两个量度SQL语句的命令。 本文主要基于 MySQL5.6 讲解其用法，因为之后的MySQL版本会去掉 show profile 功能。 SQL脚本 本篇使用的表结构以及数据如下 /*Table structure for table `dept` */ CREATE TABLE `dept` ( `deptno` int(2) NOT NULL, `dname` varchar(15) DEFAULT NULL, `loc` varchar(15) DEFAULT NULL, PRIMARY KEY (`deptno`) USING BTREE, UNIQUE KEY `index_dept_dname` (`dname`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=COMPACT; /*Data for the table `dept` */ insert into `dept`(`deptno`,`dname`,`loc`) values (10,'ACCOUNTING','NewYork'), (20,'RESEARCH','Dallas')

《 迅猛定位低效SQL？ 》留了一个尾巴： select id,name where name='shenjian' select id,name ,sex where name='shenjian' 多查询了一个属性，为何检索过程完全不同？ 什么是回表查询？ 什么是索引覆盖？ 如何实现索引覆盖？ 哪些场景，可以利用索引覆盖来优化SQL？ 这些，这是今天要分享的内容。 画外音：本文试验基于MySQL5.6-InnoDB。 一、什么是回表查询？ 这先要从InnoDB的索引实现说起，InnoDB有两大类索引： 聚集索引(clustered index) 普通索引(secondary index) InnoDB聚集索引和普通索引有什么差异？ InnoDB 聚集索引 的叶子节点存储行记录，因此， InnoDB必须要有，且只有一个聚集索引： （1）如果表定义了PK，则PK就是聚集索引； （2）如果表没有定义PK，则第一个not NULL unique列是聚集索引； （3）否则，InnoDB会创建一个隐藏的row-id作为聚集索引； 画外音：所以PK查询非常快，直接定位行记录。 InnoDB 普通索引 的叶子节点存储主键值。 画外音：注意，不是存储行记录头指针，MyISAM的索引叶子节点存储记录指针。 举个栗子，不妨设有表： t(id PK, name KEY, sex, flag); 画外音

文章目录 官方文档 概述 示例 大表数据的分批处理 修改大表的表结构 方案一 : 从表修改，主从切换 方案二： pt-online-schema-change 官方文档 https://dev.mysql.com/doc/ 如果英文不好的话，可以参考 searchdoc 翻译的中文版本 http://www.searchdoc.cn/rdbms/mysql/dev.mysql.com/doc/refman/5.7/en/index.com.coder114.cn.html 概述 MySQL-获取有性能问题SQL的方法_慢查询 & 实时获取 MySQL- SQL执行计划 & 统计SQL执行每阶段的耗时 上面两篇文章我们知道了如何获取有问题的SQL，以及如何统计SQL每个阶段的耗时，这样我们去优化的时候就更加有针对性。 这里我们列举几个例子，来看下如何具体的优化SQL 示例 大表数据的分批处理 分批处理大表的数据，特别是主从复制的MySQL集群， 每处理一批最好留一点时间，给主从同步复制留一点时间。 举个例子 有个大表 1千万数据，我们要修改其中的100万， 那么最好分多个批次来更新，每次5000或者1万，根据自己服务器的性能合理的调整。 存过如下， 根据自己的业务调整。 DELIMITER $$ USE ` artisan ` $$ DROP PROCEDURE IF EXISTS

数据库锁 共享锁(Shared lock) 例1： ---------------------------------------- T1: select * from table (请想象它需要执行1个小时之久，后面的sql语句请都这么想象） T2: update table set column1='hello' 过程：T1运行 （加共享锁) T2运行等待T1运行完之后再运行T2 之所以要等，是因为T2在执行update前，试图对table表加一个排他锁，而数据库规定同一资源上不能同时共存共享锁和排他锁。所以T2必须等T1执行完，释放了共享锁，才能加上排他锁，然后才能开始执行update语句。 例2： ---------------------------------------- T1: select * from table T2: select * from table 这里T2不用等待T1执行完，而是可以马上执行。 分析： T1运行，则table被加锁，比如叫lockA T2运行，再对table加一个共享锁，比如叫lockB。 两个锁是可以同时存在于同一资源上的（比如同一个表上）。这被称为共享锁与共享锁兼容。这意味着共享锁不阻止其它session同时读资源，但阻止其它session update 例3： ---------------------------------