mysql执行计划

MySQL高级

别等时光非礼了梦想. 提交于 2019-12-02 09:24:13
文章目录 MySQL高级 下载与安装 修改配置文件 设置字符集 mysql架构 连接层 服务层 引擎层 存储层 存储引擎 MyISAM和InnoDB 索引 索引优势 索引劣势 索引分类 基本语法 索引结构 需要创建索引的条件 不需要创建索引的情况 性能分析 MySQL Query Optimizer MySQL常见瓶颈 Explain explain字段解释 索引优化 索引分析 索引失效 注意 查询截取分析 查询优化 order by关键字优化 group by关键字优化 慢查询日志 慢查询日志查看与开启 日志分析工具mysqldumpslow 批量数据脚本 随机产生字符串 随机产生范围数字 存储过程批量插入数据 show profile 分析步骤 全局查询日志 mysql锁机制 锁的分类 三锁(表、行、页) 表锁(偏读) 表锁分析 行锁(偏写) 并发事务处理的问题 事务隔离级别 无索引行锁升级为表锁 间隙锁的危害 如何锁定一行 行锁分析 优化建议 页锁 主从复制 复制基本原理 复制基本规则 一主一从配置 MySQL高级 下载与安装 MySQL下载地址 安装 rpm -ivh MySQL-server-5.5.48-1.linux2.6.x86_64.rpm rpm -ivh MySQL-client-5.5.48-1.linux2.6.x86_64.rpm 修改初始密码 /usr

mysql 索引基本概念

人盡茶涼 提交于 2019-12-02 06:28:51
1. 什么是索引? 索引是一种数据结构,可以帮助我们快速的进行数据的查找. 2. 索引是个什么样的数据结构呢? 索引的数据结构和具体存储引擎的实现有关, 在MySQL中使用较多的索引有Hash索引,B+树索引等,而我们经常使用的InnoDB存储引擎的默认索引实现为:B+树索引. 3. Hash索引和B+树所有有什么区别或者说优劣呢? 首先要知道Hash索引和B+树索引的底层实现原理: hash索引底层就是hash表,进行查找时,调用一次hash函数就可以获取到相应的键值,之后进行回表查询获得实际数据.B+树底层实现是多路平衡查找树.对于每一次的查询都是从根节点出发,查找到叶子节点方可以获得所查键值,然后根据查询判断是否需要回表查询数据. 那么可以看出他们有以下的不同: hash索引进行等值查询更快(一般情况下),但是却无法进行范围查询. 因为在hash索引中经过hash函数建立索引之后,索引的顺序与原顺序无法保持一致,不能支持范围查询.而B+树的的所有节点皆遵循(左节点小于父节点,右节点大于父节点,多叉树也类似),天然支持范围. hash索引不支持使用索引进行排序,原理同上. hash索引不支持模糊查询以及多列索引的最左前缀匹配.原理也是因为hash函数的不可预测. AAAA 和 AAAAB 的索引没有相关性. hash索引任何时候都避免不了回表查询数据,而B+树在符合某些条件

MySQL 性能优化之骨灰级,高阶神技

我的梦境 提交于 2019-12-02 06:12:11
作者 | 惨绿少年 链接 | https://clsn.io/clsn/lx287.html 一、前言 MySQL调优对于很多程序员而言,都是一个非常棘手的问题,多数情况都是因为对数据库出现问题的情况和处理思路不清晰。在进行MySQL的优化之前必须要了解的就是MySQL的查询过程,很多的查询优化工作实际上就是遵循一些原则让MySQL的优化器能够按照预想的合理方式运行而已。 今天给大家讲解MySQL的优化实战,助你高薪之路顺畅! 图片描述(最多50字) 二、优化的哲学 注意:优化有风险,涉足需谨慎! 1、优化可能带来的问题 优化不总是对一个单纯的环境进行,还很可能是一个复杂的已投产的系统。 优化手段本来就有很大的风险,只不过你没能力意识到和预见到! 任何的技术可以解决一个问题,但必然存在带来一个问题的风险! 对于优化来说解决问题而带来的问题,控制在可接受的范围内才是有成果。 保持现状或出现更差的情况都是失败! 2、优化的需求 稳定性和业务可持续性,通常比性能更重要! 优化不可避免涉及到变更,变更就有风险! 优化使性能变好,维持和变差是等概率事件! 切记优化,应该是各部门协同,共同参与的工作,任何单一部门都不能对数据库进行优化! 所以优化工作,是由业务需要驱使的!!! 3、优化由谁参与 在进行数据库优化时,应由数据库管理员、业务部门代表、应用程序架构师、应用程序设计人员

Mysql优化(二)

僤鯓⒐⒋嵵緔 提交于 2019-12-02 06:11:29
场景 我用的数据库是mysql5.6,下面简单的介绍下场景 课程表: create table Course(c_id int PRIMARY KEY,name varchar(10)) 数据100条 学生表: create table Student(id int PRIMARY KEY,name varchar(10)) 数据70000条 学生成绩表SC CREATE table SC(sc_id int PRIMARY KEY,s_id int,c_id int,score int) 数据70w条 查询目的:查找语文考100分的考生 查询语句: select s.* from Student swhere s.s_id in (select s_id from SC scwhere sc.c_id = 0 and sc.score = 100 ) 执行时间: 30248.271s 晕,为什么这么慢,先来查看下查询计划: EXPLAIN select s.* from Student swhere s.s_id in(select s_id from SC scwhere sc.c_id = 0 and sc.score = 100) 发现没有用到索引,type全是ALL,那么首先想到的就是建立一个索引,建立索引的字段当然是在where条件的字段。 先给sc表的c

索引补充

…衆ロ難τιáo~ 提交于 2019-12-02 05:52:19
1、索引   索引是表的目录,在查找内容之前可以先在目录中查找索引位置,以此快速定位查询数据。对于索引,会保存在额外的文件中。 2、索引种类 普通索引:仅加速查询 唯一索引:加速查询 + 列值唯一(可以有null) 主键索引:加速查询 + 列值唯一 + 表中只有一个(不可以有null) 组合索引:多列值组成一个索引, 专门用于组合搜索,其效率大于索引合并 全文索引:对文本的内容进行分词,进行搜索 索引合并,使用多个单列索引组合搜索 覆盖索引,select的数据列只用从索引中就能够取得,不必读取数据行,换句话说查询列要被所建的索引覆盖 3、相关命令 - 查看表结构 desc 表名 - 查看生成表的SQL show create table 表名 - 查看索引 show index from 表名 - 查看执行时间 set profiling = 1; SQL... show profiles; 4、使用索引和不使用索引 由于索引是专门用于加速搜索而生,所以加上索引之后,查询效率会快到飞起来。 # 有索引 mysql> select * from tb1 where name = 'wupeiqi-888'; +-----+-------------+---------------------+----------------------------------+-----------

PostgreSQL与MySQL比较

試著忘記壹切 提交于 2019-12-02 05:23:39
本帖最后由 osdba 于 2011-04-21 16:33 编辑 特性 MySQL PostgreSQL 实例 通过执行 MySQL 命令(mysqld)启动实例。一个实例可以管理一个或多个数据库。一台服务器可以运行多个 mysqld 实例。一个实例管理器可以监视 mysqld 的各个实例。 通过执行 Postmaster 进程(pg_ctl)启动实例。一个实例可以管理一个或多个数据库,这些数据库组成一个集群。集群是磁盘上的一个区域,这个区域在安装时初始化并由一个目录组成,所有数据都存储在这个目录中。使用 initdb 创建第一个数据库。一台机器上可以启动多个实例。 数据库 数据库是命名的对象集合,是与实例中的其他数据库分离的实体。一个 MySQL 实例中的所有数据库共享同一个系统编目。 数据库是命名的对象集合,每个数据库是与其他数据库分离的实体。每个数据库有自己的系统编目,但是所有数据库共享 pg_databases。 数据缓冲区 通过 innodb_buffer_pool_size 配置参数设置数据缓冲区。这个参数是内存缓冲区的字节数,InnoDB 使用这个缓冲区来缓存表的数据和索引。在专用的数据库服务器上,这个参数最高可以设置为机器物理内存量的 80%。 Shared_buffers 缓存。在默认情况下分配 64 个缓冲区。默认的块大小是 8K。可以通过设置

[MySQL优化案例]系列 — 分页优化

旧巷老猫 提交于 2019-12-02 02:08:07
通常,我们会采用ORDER BY LIMIT start, offset 的方式来进行分页查询。例如下面这个SQL: SELECT * FROM `t1` WHERE ftype=1 ORDER BY id DESC LIMIT 100, 10; 或者像下面这个不带任何条件的分页SQL: SELECT * FROM `t1` ORDER BY id DESC LIMIT 100, 10; 一般而言,分页SQL的耗时随着 start 值的增加而急剧增加,我们来看下面这2个不同起始值的分页SQL执行耗时: yejr@imysql.com> SELECT * FROM `t1` WHERE ftype=1 ORDER BY id DESC LIMIT 500, 10; … 10 rows in set (0.05 sec) yejr@imysql.com> SELECT * FROM `t1` WHERE ftype=6 ORDER BY id DESC LIMIT 935500, 10; … 10 rows in set (2.39 sec) 可以看到,随着分页数量的增加,SQL查询耗时也有数十倍增加,显然不科学。今天我们就来分析下,如何能优化这个分页方案。 一般滴,想要优化分页的终极方案就是:没有分页,哈哈哈~~~,不要说我讲废话,确实如此,可以把分页算法交给Sphinx

MySql性能优化知识整理

人走茶凉 提交于 2019-12-01 21:30:44
一、数据类型 慷慨是不明智的,举例varchar(5)和varchar(200)存储‘Word’的空间是一样的,那为什么又说慷慨是不明智的呢? 实验证明更长的列会消耗更多的内存,因为mysql通常会分配固定大小的内存块来保存内部值。尤其是使用内存临时表进行排序或操作时会特别槽糕。 所以最好的策略是只分配真正需要的空间。所以什么数据选择怎样的数据类型也是很重要的。对于钱,提一句,使用int或者bigint进行存储就够了。 二、查询优化 1.切分查询 有时候对于一个大查询我们需要“分而治之”,将大查询切分成小查询,每个查询功能完全一样,值完成一小部分,每次只返回一下部分结果。删除旧的数据就是一个很好的列子。定期地清除大量数据时,如果用一个大的语句一次性完成的话,则可能需要一次锁住很多数据,占满整个事务日志,耗尽系统资源,阻塞很多小的但重要的查询。将一个大的delete语句切分多个较小的查询可以尽可能小地影响mysql性能,同时还可以减少mysql复制的延迟。例如:我们需要每个月运行一次下面的查询: delete from message where create < date_sub(NOW(),INTERVAL 3 MONTH) 那么可以用类似下面的方法来完成: rows_affected = 0 do { rows_affected = do_query( "delete from

Mysql数据库常用语句笔记

纵饮孤独 提交于 2019-12-01 17:59:24
一、连接MySQL 格式: mysql -h 主机地址 -u 用户名 -p 用户密码 1、例1:连接到本机上的MYSQL。 首先在打开DOS窗口,然后进入目录 mysql bin,再键入命令mysql -uroot -p,回车后提示你输密码,如果刚安装好MYSQL,超级用户root是没有密码的,故直接回车即可进入到MYSQL中了,MYSQL的提示符是: mysql>。 2、例2:连接到远程主机上的MYSQL。假设远程主机的IP为:110.110.110.110,用户名为root,密码为abcd123。则键入以下命令: mysql -h 110.110.110.110 -uroot -p abcd123 (注:u与root可以不用加空格,其它也一样) 3、退出MYSQL命令: exit (回车)。 二、修改密码 格式:mysqladmin -u用户名 -p旧密码 password 新密码 1、例1:给root加个密码ab12。首先在DOS下进入目录mysql bin,然后键入以下命令: mysqladmin -uroot -password ab12 注:因为开始时root没有密码,所以-p旧密码一项就可以省略了。 2、例2:再将root的密码改为djg345。 mysqladmin -uroot -pab12 password djg345 三、增加新用户。 (注意:和上面不同

数据库设计-Mysql数据库表设计的过程中几个关键点

╄→尐↘猪︶ㄣ 提交于 2019-12-01 15:28:34
一.表设计过程中应该注意的数据类型 1)更小的通常更好 控制字节长度 2)使用合适的数据类型: 如tinyint只占8个位,char(1024)与varchar(1024)的对比,char用于类似定长数据存储比varchar节省空间,如:uuid(32),可以用char(32). 3)尽量避免NULL建议使用NOT NULL DEFAULT '' 4)NULL的列会让索引统计和值比较都更复杂。可为NULL的列会占据更多的磁盘空间,在Mysql中也需要更多复杂的处理程 二.索引设计过程中应该注意的点: 1)选择唯一性索引 唯一性索引的值是唯一的,可以更快速的通过该索引来确定某条记录,保证物理上面唯一 2)为经常需要排序、分组和联合操作的字段建立索引 ,经常需要ORDER BY、GROUP BY、DISTINCT和UNION等操作的字段,排序操作会浪费很多时间 3)常作为查询条件的字段建立索引 如果某个字段经常用来做查询条件,那么该字段的查询速度会影响整个表的查询速 4)数据少的地方不必建立索引:例如gender性别字段,仅有男女2中数据, 如果在这个字段建立索引,缺点:1.索引占用内存,2.索引性能差 三.关于SQL的执行计划   使用explain关键字可以分析SQL的执行计划   下面是对比图: 数据少的字段建立索引   建立索引前   建议索引后(性能提升较少)