mysql执行计划

MySQL数据库优化 1-1MySQL优化简介 数据库优化的目的 避免出现页面访问错误 由于数据库连接timeout产生5XX错误 由于慢查询造成页面无法加载 由于阻塞造成数据无法提交 增加数据库的稳定性 很多数据库的问题都是由于低效查询引起的 优化用户体验 流畅页面的访问速度 良好的网站功能体验 可以从以下几个方面进行数据库优化 MySQL数据库优化： 1.SQL语句优化 2.有效的索引 3.数据库的表结构 4.Linux系统配置优化：打开的文件数等 5.硬件：更加适合数据库系统的cpu、更快的io：ssd等、更多的内存... 2-1数据准备 Sakila样本数据库介绍 下载Sakila样本数据库，下载地址http://downloads.mysql.com/docs/sakila-db.tar.gz(下载页面http://dev.mysql.com/doc/index-other.html)。 导入sakila-schema.sql和sakila-data.sql文件 首先下载mysql5. 7 .18 zip安装包，配置环境变量 bin文件夹下建立my.ini [ mysqld ] basedir = E:\Program Files (x86)\mysql - 5.7 . 24 - winx64\mysql - 5.7 . 24 - winx64\bin datadir =

大家好，我是烤鸭： 这是根据官方文档提炼出的mysql性能优化总结。 想看完整翻译版的请看 https://blog.csdn.net/Angry_Mills/article/details/87720396 1. 成本优化 成本包含： IO 和 CPU 从硬盘读取的花费 模型包含： 全表扫描（IO成本：表中的pages * IO阻塞读取成本 CPU成本： 行 * 行计算成本） 和 范围索引扫描（IO成本：范围中的行 * IO阻塞读取成本 IO成本：范围中的行 * 行计算成本） 2. 利用工具监视sql MySQL Enterprise Monitor (MEM), Query Analyzer Performance schema 执行计划 events_statements_history , events_statements_history_long 大部分最近执行的statement events_statements_summary_by_digest 总结相似操作（相同的statement合并） file_summary_by_event_name Interesting event: wait/io/file/innodb/innodb_data_file table_io_waits_summary_by_table table_io_waits_summary

1 登录数据库 格式： mysql -h主机地址 -u用户名 －p用户密码–P端口 –D数据库–e “SQL 内容” >mysql -uroot -p 数据库名称 2 修改密码 mysqladmin -u用户名 -p旧密码 password 新密码 Mysqladmin -uroot -password test1 注：因为开始时root没有密码，所以-p旧密码一项就可以省略了。 例2：再将root的密码改为test1。 mysqladmin-uroot -ptest1 password test2 3 添加用户 格式：grant select on 数据库.* to 用户名@登录主机 identified by “密码” 例1、增加一个用户test1密码为abc，让他可以在任何主机上登录，并对所有数据库有查询、插入、修改、删除的权限。首先用以root用户连入MySQL，然后键入以下命令： grant select,insert,update,deleteon *.* to test2@localhost identified by\"abc\"; 如果你不想test2有密码，可以再打一个命令将密码消掉。 grantselect,insert,update,delete on mydb.* to test2@localhostidentified by \"\"; 4 创建数据库

【 背景 】 　　周末比较闲，我这个人又没有什么爱好，当然了读书除外；前一些天我一个同事说：“你一个dba想去写一本“django”书，合适吗？” 　　我想也是，一个人不能忘了本，所以MySQL还是要好好的搞一搞的；自那时起决定每周至少要写一篇MySQL博客，技术这东西不进则退 　　刚刚看官方文档的时候吓到了，本以为官方写的SQL应该是比较好的，是同一类问题的最佳实践，没想到并不是这样的； 　　 The Row Holding the Maximum of a Certain Column 这一章节我就觉得有问题 【 问题介绍 】 　　假设我们建了一个用于保存商品信息的表，那我们如何查出最贵的商品是哪件呢？ drop table if exists shop; create table if not exists shop ( article int ( 4 ) UNSIGNED ZEROFILL default ' 0000 ' not null , dealer char ( 20 ) default '' not null , price double ( 16 , 2 ) default ' 0.00 ' not null , primary key (article, dealer), INDEX shop__price(price)); insert into shop

explain 详解： 作用：主要用来调取语句的执行计划，主要是判断语句是否走索引。 explain select stu_name,gender,age from stu where gender='F' and age <20; mysql> explain select name,gender,age from test where gender='F' and age <20; +----+-------------+-------+-------+---------------+----------+---------+------+------+-----------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------+-------+---------------+----------+---------+------+------+-----------------------+ | 1 | SIMPLE | test | range | inx_test | inx_test | 7 | NULL | 1 | Using index condition |

MySQL数据库中索引的类型介绍 BTREE:B+树索引 （日常所见大部分为此种索引） HASH：HASH索引 FULLTEXT：全文索引 RTREE：R树索引 MySQL索引管理 索引建立在表的列上(字段)的。 在where后面的列建立索引才会加快查询速度。 pages<---索引（属性）<----查数据。 索引分类： 　　主键索引 　　普通索引 　　唯一索引 添加索引和删除索引的两种方式 第一种： alter table test add index index_name(name); alter table test drop index idx_name; 　　 第二种： create index index_name on test(name); drop index idx_stu_name on t1; 　　 查看索引的两种方式 第一种方式： mysql> desc t1; +----------+-------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +----------+-------------+------+-----+---------+-------+ | id | int(5) | YES | | NULL | | |

在进行 MySQL 的优化之前必须要了解的就是 MySQL 的查询过程，很多的查询优化工作实际上就是遵循一些原则让 MySQL 的优化器能够按照预想的合理方式运行而已。 图 - MySQL查询过程 优化的哲学 优化有风险，涉足需谨慎。 优化可能带来的问题 优化不总是对一个单纯的环境进行，还很可能是一个复杂的已投产的系统。 优化手段本来就有很大的风险，只不过你没能力意识到和预见到！ 任何的技术可以解决一个问题，但必然存在带来一个问题的风险！ 对于优化来说解决问题而带来的问题,控制在可接受的范围内才是有成果。 保持现状或出现更差的情况都是失败！ 优化的需求 稳定性和业务可持续性,通常比性能更重要！ 优化不可避免涉及到变更，变更就有风险！ 优化使性能变好，维持和变差是等概率事件！ 切记优化,应该是各部门协同，共同参与的工作，任何单一部门都不能对数据库进行优化！ 所以优化工作,是由业务需要驱使的！！！ 优化由谁参与 　　在进行数据库优化时，应由数据库管理员、业务部门代表、应用程序架构师、应用程序设计人员、应用程序开发人员、硬件及系统管理员、存储管理员等，业务相关人员共同参与。 优化思路 优化什么 在数据库优化上有两个主要方面：即安全与性能。 安全 ---> 数据可持续性 性能 ---> 数据的高性能访问 优化的范围有哪些 存储、主机和操作系统方面 主机架构稳定性 I/O 规划及配置

项目刚刚告一段落，boos又让优化几个主要界面 程序代码方便的优化就不讲了，主要说MySQL的优化 首先查看explain执行计划，让主要查询语句使用索引，索引type级别最好达到ref | ref_eq级别 其次将extra一栏的Using temporary（临时表）、Using filesort（文件排序）拖出去砍了 第一条语句 explain select * from tb_wm_shop where is_delete != 1 and is_authentication = 1 ORDER BY create_time DESC 大家应该知道使用order by的 字段要使用索引，这条语句中create_time已经创建了索引，但是计划中并没有使用该索引，导致出现了Using filesort文件排序，使其查询变慢 解决方法如下： 从where条件开始，依照顺序创建一个组合索引，就可以砍掉Using filesort这个令人讨厌的头颅了 注意：必须依照顺序，在创建组合索引时，where条件的字段在orderBy的字段之前，如果orderBy是多字段，则必须依照顺序创建 详情可参考链接： https://blog.csdn.net/dingxingmei/article/details/49096591 第二条语句 explain select s.* from tb

　　Coinciding with the new native data dictionary in MySQL 8.0, we have made a number of useful enhancements to our INFORMATION_SCHEMA subsystem design in MySQL 8.0. In this post I will first go through our legacy implementation as it has stood since MySQL 5.1, and then cover what’s changed. 　　与MySQL 8.0原生数据字典一致，在MySQL 8.0的INFORMATION_SCHEMA子系统设计中，我们做了一些很有用的增强。在这篇文章中，我将会介绍自MySQL 5.1以来的旧的实现方式，然后介绍我们做了什么改变。 　　Background 　　INFORMATION_SCHEMA was first introduced into MySQL 5.0, as a standards compliant way of retrieving meta data from a running MySQL server. When we look at the history of

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