mysql执行计划

key_len表示索引使用的字节数，根据这个值可以判断索引的使用情况,特别是在组合索引的时候,判断该索引有多少部分被使用到非常重要。 在计算key_len时，下面是一些需要考虑的点: 索引字段的附加信息: 可以分为变长和定长数据类型讨论，当索引字段为定长数据类型时,如char，int，datetime,需要有是否为空的标记,这个标记占用1个字节(对于not null的字段来说,则不需要这1字节);对于变长数据类型,比如varchar,除了是否为空的标记外,还需要有长度信息,需要占用两个字节。 对于,char、varchar、blob、text等字符集来说，key len的长度还和字符集有关,latin1一个字符占用1个字节,gbk一个字符占用2个字节,utf8一个字符占用3个字节。 综上，下面来看一些例子: 列类型 KEY_LEN 备注 id int key_len = 4+1 int为4bytes,允许为NULL,加1byte id bigint not null key_len=8 bigint为8bytes user char(30) utf8 key_len=30*3+1 utf8每个字符为3bytes,允许为NULL,加1byte user varchar(30) not null utf8 key_len=30*3+2 utf8每个字符为3bytes,变长数据类型

一、MySQL 的主要适用场景 1、Web网站系统 2、日志记录系统 3、数据仓库系统 4、嵌入式系统 二、 MySQL 架构图： 三、 MySQL 存储引擎概述 1 ） MyISAM 存储引擎 MyISAM存储引擎的表在数据库中，每一个表都被存放为三个以表名命名的物理文件。首先肯定会有任何存储引擎都不可缺少的存放表结构定义信息的.frm文件，另外还有.MYD和.MYI文件，分别存放了表的数据（.MYD）和索引数据（.MYI）。每个表都有且仅有这样三个文件做为MyISAM存储类型的表的存储，也就是说不管这个表有多少个索引，都是存放在同一个.MYI文件中。 MyISAM支持以下三种类型的索引： 1、B-Tree索引 B-Tree索引，顾名思义，就是所有的索引节点都按照balancetree的数据结构来存储，所有的索引数据节点都在叶节点。 2、R-Tree索引 R-Tree索引的存储方式和b-tree索引有一些区别，主要设计用于为存储空间和多维数据的字段做索引，所以目前的MySQL版本来说，也仅支持geometry类型的字段作索引。 3、Full-text索引 Full-text索引就是我们长说的全文索引，他的存储结构也是b-tree。主要是为了解决在我们需要用like查询的低效问题。 2 ） Innodb 存储引擎 1、支持事务安装 2、数据多版本读取 3、锁定机制的改进 4

MySQL架构 查询执行流程 查询执行的流程是怎样的： 连接 1.1客户端发起一条Query请求，监听客户端的‘连接管理模块’接收请求 1.2将请求转发到‘连接进/线程模块’ 1.3调用‘用户模块’来进行授权检查 1.4通过检查后，‘连接进/线程模块’从‘线程连接池’中取出空闲的被缓存的连接线程和客户端请求对接，如果失败则创建一个新的连接请求。 处理 2.1先查询缓存，检查Query语句是否完全匹配， 2.2查询缓存失败则转交给‘命令解析器’ 2.3再转交给对应的模块处理 2.4如果是SELECT查询还会经由‘查询优化器’做大量的优化，生成执行计划 2.5模块收到请求后，通过‘访问控制模块’检查所连接的用户是否有访问目标表和目标字段的权限 2.6有则调用‘表管理模块’，先是查看table cache中是否存在，有则直接对应的表和获取锁，否则重新打开表文件 2.8根据表的meta数据，获取表的存储引擎类型等信息，通过接口调用对应的存储引擎处理 2.9上述过程中产生数据变化的时候，若打开日志功能，则会记录到相应二进制日志文件中 结果 3.1Query请求完成后，将结果集返回给‘连接进/线程模块’ 3.2返回的也可以是相应的状态标识，如成功或失败等 3.3‘连接进/线程模块’进行后续的清理工作，并继续等待请求或断开与客户端的连接 什么是优化 合理安排资源、调整系统参数使MySQL运行更快

引言： 实际项目开发中，由于我们不知道实际查询的时候数据库里发生了什么事情，数据库软件是怎样扫描表、怎样使用索引的，因此，我们能感知到的就只有 sql语句运行的时间，在数据规模不大时，查询是瞬间的，因此，在写sql语句的时候就很少考虑到性能的问题。但是当数据规模增大，如千万、亿的时候，我们运 行同样的sql语句时却发现迟迟没有结果，这个时候才知道数据规模已经限制了我们查询的速度。所以，查询优化和索引也就显得很重要了。 问题： 当我们在查询前能否预先估计查询究竟要涉及多少行、使用哪些索引、运行时间呢？答案是能的，mysql提供了相应的功能和语法来实现该功能。 分析： 1、MySQL语法 MySql提供了EXPLAIN语法用来进行查询分析，在SQL语句前加一个”EXPLAIN”即可。 默认情况下Mysql的profiling是关闭的，所以首先必须打开profiling set profiling="ON" mysql> show variables like "%profi%"; +------------------------+-------+ | Variable_name | Value | +------------------------+-------+ | profiling | ON | show processlist; 查看现在在运行的所有进程列表

mysql的二进制日志 记录了所有对MySQL数据库的数据增删查改和对表和数据库的修改,需要在myc.cnf配置文件中进行配置 基于段的日志格式：binlog_format=STATEMENT 基于行的日志格式：binlog_format=ROW binlog_row_image=[FULL|MINIMAL|NOBLOB] 混合日志格式：binlog_format=MIXED 根据sql语句由系统决定使用基于段还是基于行的日志格式； 数据量的大小由所执行的sql语句决定 建议使用binlog_format=MIXED 或者 binlog_format=ROW并设置binlog_row_image=MINIMAL 查看二进制日志：mysqlbinlog -vv 日志文件名称，比如： mysqlbinlog -vv mysql-bin.000002 log_bin = mysql-bin # 开启及设置二进制日志文件名称 binlog_format = MIXED # 混合日志格式 sync_binlog = 1 # 二进制日志（binary log）同步到磁盘的频率 rpl_semi_sync_master_wait_point = after_sync expire_logs_days =7 #二进制日志自动删除/过期的天数。默认值为0，表示不自动删除。 数据库优化的几个方面 (1

Mysql优化可分为三部分：索引的优化、SQL语句优化、表的优化 索引优化可以遵循以下几个原则： 联合索引最左前缀匹配原则 尽量把字段长度小的列放在联合索引的最左侧（字段越小，一页存储的数据量越大，IO性能就越好） order by 有多个列排序的，应该建立联合索引 对于频繁的查询优先考虑使用覆盖索引 前导模糊查询不会使用索引，比如：like %aaa% 负向条件不会使用索引，如 !=,<>,not like,not in,not exists 对于where子句中经常使用的列，最好设置索引 SQL语句优化，可以通过explain查看SQL的执行计划，优化语句原则： 在where和order by涉及的列上建立合适的索引，避免全表扫描 任何查询都不要使用select *，而是用具体的字段代替 多表连接时，尽量小表驱动大表，即小表join大表 用exists代替in 尽量避免在where子句中对字段进行函数操作 数据库表优化： 表字段尽可能用not null 字段长度固定表查询会更快 将数据库大表按照时间或者一些标志拆分成小表 水平拆分：将记录散列到不同的表中，每次从分表查询 垂直拆分：将表中的大字段单独拆分到另一张表，形成一对一的关系 来源： https://www.cnblogs.com/zouhg/p/11637497.html

一、今日内容概要 在你开发应用的时候，一定会经常碰到需要根据指定的字段排序来显示结果的需求。还是以我们前面举例用过的市民表为例，假设你要查询城市是“杭州”的所有人名字，并且按 照姓名排序返回前 1000 个人的姓名、年龄。 假设这个表的部分定义是这样的： CREATE TABLE `t` ( `id` int(11) NOT NULL, `city` varchar(16) NOT NULL, `name` varchar(16) NOT NULL, `age` int(11) NOT NULL, `addr` varchar(128) DEFAULT NULL, PRIMARY KEY (`id`), KEY `city` (`city`) ) ENGINE=InnoDB; 这时，你的 SQL 语句可以这么写： select city,name,age from t where city='杭州' order by name limit 1000 ; 这个语句看上去逻辑很清晰，但是你了解它的执行流程吗？今天，我就和你聊聊这个语句是怎么执行的，以及有什么参数会影响执行的行为 二、全字段排序 前面我们介绍过索引，所以你现在就很清楚了，为避免全表扫描，我们需要在 city 字段加上索引。 在 city 字段上创建索引之后，我们用 explain 命令来看看这个语句的执行情况。 图 1

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。 本文链接：https://blog.csdn.net/samjustin1/article/details/52314813 第一方面：30种mysql优化sql语句查询的方法 1.对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。 　　2.应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。 　　3.应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如： 　　select id from t where num is null 　　可以在num上设置默认值0，确保表中num列没有null值，然后这样查询： 　　select id from t where num=0 　　4.应尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如： 　　select id from t where num=10 or num=20 　　可以这样查询： 　　select id from t where num=10 　　union all 　　select id from t where num=20 　

在工作之中，由于SQL问题导致的数据库故障层出不穷，索引问题是SQL问题中出现频率最高的，常见的索引问题包括：无索引，隐式转换，索引创建不合理。 当数据库中出现访问表的SQL没创建索引导致全表扫描，如果表的数据量很大扫描大量的数据，执行效率过慢，占用数据库连接，连接数堆积很快达到数据库的最大连接数设置，新的应用请求将会被拒绝导致故障发生。 隐式转换是指SQL查询条件中的传入值与对应字段的数据定义不一致导致索引无法使用。常见隐式转换如字段的表结构定义为字符类型，但SQL传入值为数字；或者是字段定义collation为区分大小写，在多表关联的场景下，其表的关联字段大小写敏感定义各不相同。隐式转换会导致索引无法使用，进而出现上述慢SQL堆积数据库连接数跑满的情况。 索引使用策略及优化 创建索引 在经常查询而不经常增删改操作的字段加索引。 order by与group by后应直接使用字段，而且字段应该是索引字段。 一个表上的索引不应该超过6个。 索引字段的长度固定，且长度较短。 索引字段重复不能过多。 在过滤性高的字段上加索引。 使用索引注意事项 使用like关键字时，前置%会导致索引失效。 使用null值会被自动从索引中排除，索引一般不会建立在有空值的列上。 使用or关键字时，or左右字段如果存在一个没有索引，有索引字段也会失效。 使用!=操作符时，将放弃使用索引。因为范围不确定

我们对mysql表建立了索引之后怎么查看索引的使用情况呢？ 这时候，我们就需要explain执行计划来帮助了。 1.语法 EXPLAIN SELECT column1,column2 FROM table [where ... ] 2.explain详细信息 2.1概要描述： id:选择标识符 select_type:表示查询的类型。 table:输出结果集的表 type:表示表的连接类型 possible_keys:表示查询时，可能使用的索引 key:表示实际使用的索引 key_len:索引字段是否被充分使用 ref:列与索引的比较 rows:扫描出的行数(估算的行数) Extra:执行情况的描述和说明 2.2 select_type： 显示查询中每个select子句的类型 (1) SIMPLE(简单SELECT，不使用UNION或子查询等) (2) PRIMARY(子查询中最外层查询，查询中若包含任何复杂的子部分，最外层的select被标记为PRIMARY) (3) UNION(UNION中的第二个或后面的SELECT语句) (4) DEPENDENT UNION(UNION中的第二个或后面的SELECT语句，取决于外面的查询) (5) UNION RESULT(UNION的结果，union语句中第二个select开始后面所有select) (6) SUBQUERY