mysql执行计划

MySQL当对一列进行操作时，如果in的条件太多，即使这列上有索引，也是导致执行计划不走索引 因为搜索的记录数太多，MySQL会认为全表扫描可能会更快 对一个表进行删除操作，如果这个列上没有索引，或者执行计划没有走搜索，会导致删除锁住全部的列 sesson1 mysql> show indexes from city1; +-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+ | Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment | +-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+

微信公众号【Java技术江湖】一位阿里 Java 工程师的技术小站。作者黄小斜，专注 Java 相关技术：SSM、SpringBoot、MySQL、分布式、中间件、集群、Linux、网络、多线程，偶尔讲点Docker、ELK，同时也分享技术干货和学习经验，致力于Java全栈开发！ 一：Mysql原理与慢查询 MySQL凭借着出色的性能、低廉的成本、丰富的资源，已经成为绝大多数互联网公司的首选关系型数据库。虽然性能出色，但所谓“好马配好鞍”，如何能够更好的使用它，已经成为开发工程师的必修课，我们经常会从职位描述上看到诸如“精通MySQL”、“SQL语句优化”、“了解数据库原理”等要求。我们知道一般的应用系统，读写比例在10:1左右，而且插入操作和一般的更新操作很少出现性能问题，遇到最多的，也是最容易出问题的，还是一些复杂的查询操作，所以查询语句的优化显然是重中之重。 本人从13年7月份起，一直在美团核心业务系统部做慢查询的优化工作，共计十余个系统，累计解决和积累了上百个慢查询案例。随着业务的复杂性提升，遇到的问题千奇百怪，五花八门，匪夷所思。本文旨在以开发工程师的角度来解释数据库索引的原理和如何优化慢查询。 一个慢查询引发的思考 select count(*) from task where status=2 and operator_id=20839 and operate

MySQL常见的8种SQL错误用法 前言 MySQL在2016年仍然保持强劲的数据库流行度增长趋势。越来越多的客户将自己的应用建立在MySQL数据库之上，甚至是从Oracle迁移到MySQL上来。但也存在部分客户在使用MySQL数据库的过程中遇到一些比如响应时间慢，CPU打满等情况。 阿里云RDS专家服务团队帮助云上客户解决过很多紧急问题。现将《ApsaraDB专家诊断报告》中出现的部分常见SQL问题总结如下，供大家参考。 1、LIMIT 语句 分页查询是最常用的场景之一，但也通常也是最容易出问题的地方。 比如对于下面简单的语句，一般 DBA 想到的办法是在 type, name, create_time 字段上加组合索引。这样条件排序都能有效的利用到索引，性能迅速提升。 SELECT * FROM operation WHERE type = 'SQLStats' AND name = 'SlowLog' ORDER BY create_time LIMIT 1000, 10;复制代码 好吧，可能90%以上的 DBA 解决该问题就到此为止。 但当 LIMIT 子句变成 “LIMIT 1000000,10” 时，程序员仍然会抱怨：我只取10条记录为什么还是慢？ 要知道数据库也并不知道第1000000条记录从什么地方开始，即使有索引也需要从头计算一次。出现这种性能问题

Explain工具介绍 使用EXPLAIN关键字可以模拟优化器执行SQL语句，分析查询语句或是结构的性能瓶颈。在select语句之前增加explaion关键字，MySQL会在查询上设置一个标记，执行查询会返回执行计划的信息，而不是执行SQL。 Explaion分析示例 -- actor建表语句： CREATE TABLE `actor` ( `id` int(11) NOT NULL, `name` varchar(45) DEFAULT NULL, `update_time` datetime DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 -- film建表语句： CREATE TABLE `film` ( `id` int(11) NOT NULL, `name` varchar(10) NOT NULL, PRIMARY KEY (`id`), KEY `idx_name` (`name`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 -- film_actor建表语句： CREATE TABLE `film_actor` ( `id` int(11) NOT NULL, `film_id` int(11) NOT NULL, `actor_id`

我们经常说到mysql优化，优化中一种常见的方式就是对于经常查询的字段创建索引。那么mysql中有哪些索引类型呢？ 一、索引分类 1、普通索引：即一个索引只包含单个列，一个表可以有多个单列索引 2、唯一索引：索引列的值必须唯一，但允许有空值 3、复合索引：即一个索引包含多个列 4、聚簇索引(聚集索引)：并不是一种单独的索引类型，而是一种数据存储方式。具体细节取决于不同的实现，InnoDB的聚簇索引其实就是在同一个结构中保存了B-Tree索引(技术上来说是B+Tree)和数据行。 5、非聚簇索引：不是聚簇索引，就是非聚簇索引 二、基本语法 查看索引 SHOW INDEX FROM table_name 创建索引 CREATE [UNIQUE ] INDEX indexName ON mytable(columnname(length)); ALTER TABLE 表名 ADD [UNIQUE ] INDEX [indexName] ON (columnname(length)) 删除索引 DROP INDEX [indexName] ON mytable; 上面讲了创建索引的基本语法，现在处理讲一下如何查看执行计划。 执行计划 ：使用EXPLAIN关键字可以模拟优化器执行SQL查询语句，从而知道MySQL是如何处理你的SQL语句的。分析你的查询语句或是表结构的性能瓶颈 执行计划的作用

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

MySQL数据备份： #1. 物理备份： 直接复制数据库文件，适用于大型数据库环境。但不能恢复到异构系统中如Windows。 #2. 逻辑备份： 备份的是建表、建库、插入等操作所执行SQL语句，适用于中小型数据库，效率相对较低。 #3. 导出表： 将表导入到文本文件中。 一、使用mysqldump实现逻辑备份 #语法： # mysqldump -h 服务器 -u用户名 -p密码 数据库名 > 备份文件.sql #示例： #单库备份 mysqldump -uroot -p123 db1 > db1.sql mysqldump -uroot -p123 db1 table1 table2 > db1-table1-table2.sql #多库备份 mysqldump -uroot -p123 --databases db1 db2 mysql db3 > db1_db2_mysql_db3.sql #备份所有库 mysqldump -uroot -p123 --all-databases > all.sql 二、恢复逻辑备份 #方法一： [root@egon backup]# mysql -uroot -p123 < /backup/all.sql #方法二： mysql> use db1; mysql> SET SQL_LOG_BIN=0; mysql> source /root

转载自： Oo若离oO ，原文链接 在MySQL中使用explain查询SQL的执行计划 目录 一、什么是执行计划 二、如何分析执行计划 一、什么是执行计划 要对执行计划有个比较好的理解，需要先对MySQL的基础结构及查询基本原理有简单的了解。 MySQL本身的功能架构分为三个部分，分别是 应用层、逻辑层、物理层，不只是MySQL，其他大多数数据库产品都是按这种架构来进行划分的。 应用层：主要负责与客户端进行交互，建立链接，记住链接状态，返回数据，响应请求，这一层是和客户端打交道的。 逻辑层：主要负责查询处理、事务管理等其他数据库功能处理，以查询为例。 首先接收到查询SQL之后，数据库会立即分配一个线程对其进行处理，第一步查询处理器会对SQL查询进行优化， 优化后会生成执行计划 ，然后交由计划执行器来执行。 计划执行器需要访问更底层的事务管理器，存储管理器来操作数据，他们各自的分工各有不同，最终通过调用物理层的文件获取到查询结构信息，将最终结果响应给应用层。 物理层，实际物理磁盘上存储的文件，主要有分文数据文件，日志文件。 通过上面的描述，生成执行计划是执行一条SQL必不可少的步骤，一条SQL性能的好坏，可以通过查看执行计划很直观的看出来，执行计划提供了各种查询类型与级别，方面我们进行查看以及作为性能分析的依据。 二、如何分析执行计划 MySQL为我们提供了 explain

索引好比书的目录。通过索引能快速的定位到一条数据。 在MySQL中除了B+树索引之外，还有一些其他的索引类型。比如:全文索引、（DB和DD索引叫R树索引）。在MySQL cluster中是P树索引，memory引擎中用的是哈希索引。Oracle中的位图索引在MySQL中是没有的。 百分之九十五的时间在跟B+树索引打交道。用的最多的就是B+树索引。 指向下一层的指针就叫做扇出（fanout） B+树索引在物理上不一定是有序的例如：插入了28，有可能就会排在30的后面。 在逻辑上是有序的，是通过指针来保证逻辑上有序的，页内数据是有序的，页与页之间也是有序的。 show index from orders\G **********************1.row************************ Table: orders Non_unique: 0 　　 -- 表示是唯一的 Key_name: PRIMARY　　 -- key的name是primary Sql_in_index: 1 Column_name: o_orderkey Collation: A Cardinality: 1417233 　　 -- 基数，这个列上不重复值的数值 Sbu_part: NULL Packed: NULL Null: Index_type: BTREE 　　 --

专职DBA-MySQL优化 1.优化哲学 为什么优化？ 为了获得成就感？ 为了证实比系统设计者更懂数据库？ 为了从优化成果来证实优化者更有价值？ 但通常事实证明的结果往往会和你期待的相反！ 优化有风险，涉足需谨慎！ 2.优化风险 优化不总是对一个单纯的环境进行！还很可能是一个复杂的已投产的系统。 优化手段本来就有很大的风险，只不过你没能力意识到和预见到！ 任何的技术可以解决一个问题，但必然存在带来另一个问题的风险！ 对于优化来说解决问题而带来的问题控制在可接受的范围内才是有成果的。 优化后，保持现状或出现更差的情况都是失败！ 稳定性和业务可持续性通常比性能更重要！ 优化不可避免的就是涉及到变更，变更就有风险！ 优化使性能变好，维持和变差是等概率事件！ 优化不能只是DBA担当风险，但会所有的人分享优化成果！ 所以优化工作是由业务需要驱使的！！！ 3.谁会参与优化 数据库工程师 业务部门代表 应用程序架构师 应用程序设计人员 应用程序开发人员 硬件及系统管理员 存储管理员 网络工程师 研发人员 4.优化方向 安全优化（业务持续性） 性能优化（业务高效性） 5.优化的范围及思路 优化范围： 存储、主机和操作系统： 主机架构稳定性 I/O规划及配置 Swap OS内核参数 网络问题 应用程序：（Index，lock，session） 应用程序稳定性和性能 SQL语句性能 串行访问资源