在业界当中咱们有一个叫大数据(big data)的概念,所谓的大数据指代千万级别以上的数据做为起步的数据。因此咱们如今须要对两张都具备50331650条记录的表进行查询对比,其中表名为tbl_no的表是没有作过任何优化手段的表,表名为tbl_yes的表是作过优化手段的表。这个实验的目的是观察具备优化手段和不具备优化手段的查询中速度的差异。php
实验条件:mysql
1)两张表的数据记录总数是相同的面试
2)两张表的数据字段结构也是同样的redis
3)查询的记录的where条件都是username='itcast'的用户算法
实验结果对比出现以下的结果:sql
①表tbl_no查询条件为username='itcast'的用户耗时时间为15.59sec:shell
②表tbl_yes查询条件为username='itcast'的用户耗时时间为:0.01秒数据库
最终的对比结果以下:编程
在今天互联网当中有一个所谓的8秒原则,根据统计一个用户在8秒中以内若是不能打开一个网站,那么有99%的用户会选择关闭浏览器。vim
其实8秒原则是相对论,由于若是一个网站打开的速度超过两秒达到3秒钟才能打开其实就已经无限在挑战用户的耐心了,也就说其实咱们作优化是尽量控制速度在2秒内完成,这样才能更好的留住用户,避免挑战用户的等待耐心.
然而咱们说为何数据库的查询速度慢就会影响用户等待的耐心呢?
在开发的当中咱们使用php+mysql的架构占据了主要的开发方式,这种架构造成的请求其实真正的结果执行最终发生在MySql数据库当中,其主要流程图以下所示:
若是这个请求的过程中,数据库响应达到了?秒,那么也就就是说浏览器的客户在不断等待网站数据返回(打开),也就是这样8秒原则的定律就会成型,用户关闭浏览器的可能性是99%的.
1.表设计层面:存储引擎,索引,列类型,范式规范(冗余)
2.服务器层面:实现数据库主从复制(读写分离)
3.编程层面:避免在循环中select数据表
4.缓存层面:使用nosql技术
5.系统层面:使用Linux操做系统做为服务器底层
6.其余方面:硬件,集群服务器,靠谱的idc供应商,靠谱的技术团队
天下没有免费的午饭,任何的优化其实都具备主观的性质存在并且每一种优化的手段基本上都须要付出必定的代价。世界上没有一个很是标准的优化技术给你做为参考,优化是一门永远不会中止课题,随着你的经验的积累,那么你的优化手段和看法就有可能不一样
MySQL中的数据是经过各类不一样的技术格式存储在文件(或者内存)中的。技术和自己的特性就称为"存储引擎"。每一种需求都使用不一样的存储引擎,才能获取不一样的数据库性能和功能上的需求。
若是在生活把独门独户的楼房(纵向结构)和平房(平面结构)看做存储引擎的话,不一样的建筑结构对于不一样的需求来讲就有不一样的便利。对于送快递的人来讲,独门独户的楼房便于快递的小哥的投递。对于装空调或者搬家具的师傅来讲,平房天然更有利于空调的安装和家具的进出。
由此咱们能够知道一个结论,选择不一样的存储引擎就是选择不一样的技术格式(结构),他们的特性决定他们对某种需求的优点,所以存储引擎的正确选择是作MySql优化的关键。
在mysql数据库当中其实有5种存储引擎,而且会默认地帮用户选定其中一个,不一样的数据库版本默认的选项是不同的,因此咱们能够经过如下的命令去了解当前mysql的存储引擎相关状况:
语法规则: show engines
执行命令效果以下:
(针对5.1.73的版本)
经常使用的存储引擎通常是MyISAM和Innodb,MyIsam是默认的存储引擎
Memory其实之前也是一个很受欢迎的引擎,然而它如今已经被Memcache和redis取代它的地位了,所以使用的人就极少了,这个引擎是一个内存机制的引擎相似Memcache,但性能不如memcache强大.(了解)
在mysql中,mysql把全部的数据库用目录来表示,把数据用文件的方式来进行存储。
mysql数据库在Linux当中它的目录路径在:/var/lib/mysql
创建一个名为demo的数据库
代码参看:code/demo.sql
查询/var/lib/mysql就会发觉多了一个名为demo的目录
查看demo数据库中的myisam引擎下的表文件
在/var/lib/mysql/demo目录下,产生如下文件:
在mysql当中myisam引擎存储数据有3个文件组成
.frm文件用于存储建表的结构信息(字段信息)
.MYD用于储存表的记录信息
.MYI用于储存表的索引信息(例如:主键)
MyISAM存储引擎的特色:
建表结构,表记录信息和索引信息都独立存在的,因为MyISAM存储引擎的技术特色是结构和数据分离,所以能够更好地观察到该存储引擎的文件变化状况,所以大部分状况下咱们作优化都是使用MyISAM引擎。
实验:建立一张产品表goods,代码以下:
代码详细请参考:code/goods.sql
建表完成后,发觉/var/lib/mysql/demo下的文件有以下变化:
用复制数据的方法添加记录查看myisam引擎表的变化
第1步:向goods表添加3条记录
第2步:以倍增的方式复制数据
反复执行的结果以下:
你会很快就能够插入几十万甚至几千万条数据
第3步:查看结果发现其实文件的大小变化以下图所示:
myisam引擎的表,当数据发生变化的时候,只有.MYI文件和.MYD文件会发生变化,而.frm文件不会发生改变
在mysql中,mysql把全部的数据库用目录来表示,把数据用文件的方式来进行存储。
mysql数据库在Linux当中它的路径在:/var/lib/mysql,所以不管是Innodb的引擎仍是MyISAM引擎的表数据都存在于该目录当中,因此一样地咱们能够在这个目录中进行Innodb引擎的表文件变化。
代码详细请参考:code/pros.sql
实验:建立一张产品表pros,代码以下:
观察其实文件的变化以下:
问题来了:查看以上结果后你会发觉在Innodb只有一个.frm文件用于存储数据表的结构,那么Innodb的记录信息和索引文件存放哪里呢?
插数据来观察innodb的变化
第1步:向pros表添加3条记录
第2步:以倍增的方式复制数据
第3步:观察结果,能够得出如下结论:
被数据发觉/var/lib/msyql/demo目录没有任何的改变
然而咱们会发现若是咱们继续倍增数据在/var/lib/mysql有一个文件ibdata1会发生改变,效果以下:
很快咱们发觉会有一个这样的文件产生ibdata1,随着你对innodb的数据表pros添加数据,这个文件的大小发生了变化,由于innodb是把全部表记录信息和索引信息都共享在一个文件当中的。若是咱们有10张innodb的表那么咱们10张表的记录信息和索引信息都会存放到这个文件当中,所以咱们要针对某一张innodb的表来作优化是很难的。因此咱们证实了一点,作优化通常是针对myisam的表。
Innodb存储引擎的特色:结构和数据共享,目的是为了保证数据的完整性,为追求数据完整性和安全性而生的存储引擎。
Innodb
专一在数据完整性和安全性方面,例如:事务等,对查询,插入数据的效率支持就比较差
Myisam
MyIsam的是追求性能的而生的。所以咱们说的mysql优化其实不少时候就是针对myisam引擎而言,但优化是要付出代价的,你要优化就要牺牲掉某些东西,若是你当前的业务要求安全性很高那么你就别谈什么优化了,也不能选择myisam了。
两种存储引擎的应用场景(引擎的选择)
大量查询(select)或者写入(update,insert,delete)就选择Myisam,例如:博客系统,论坛等
数据涉及利益和金钱交易,就须要很严谨和具备安全性,例如销售、财务,股票等系统,就选择innodb
在37游戏公司当中有一个这样的业务,他们的游戏是按地区访问的,例如:你是广州的玩家,通常访问的是广州这边的游戏服务器数据,若是是你是上海的玩家那么你访问的游戏服务器数据通常是上海的,有时候总部某些游戏有更新(好比:更新的了游戏的地图),这时须要把这些游戏的更新数据进行其余地区的同步,好比同步到上海,这时就须要进行数据的迁移和复制.其原理图以下所示:
这时会产生一个这样的问题:如何提升数据迁移和复制的速度?
压缩机制的优化实际上是为了节约硬盘空间和传输文件的,对select语句的优化的最多提高可以达到0.1-0.8秒,所以解压缩机制的优化实际上并非提升select语句的手段。
MyISAM的表压缩详细步骤以下:
第1步:找到您须要压缩表文件,好比说若是但愿压缩test数据库当中tbl_yes这张表,那么我就应该切换到/var/lib/mysql/test目录,找到tbl_yes这张表文件以下:
确认在没有进行压缩优化以前的
tbl_yes.frm的大小是8.4k
tbl_yes.MYD的大小是961M
tbl_yes.MYI的大小是684M
压缩其实跟您当前计算机cpu和硬盘的性能有关系,若是你硬盘读写能力很强,cpu的核数很高,那么压缩的速度就很快,反之压缩的速度就比较,压缩数据实际上是有一个比率值的,若是用家庭电脑进行数据压缩,每一个电脑压缩的比率值是不一样,通常若是能压缩50%的比率就已经很厉害了,固然真正的服务设备通常压缩的比率高达80%以上,使用myisam的表压缩实际上是一个很是伤硬盘的过程,因此真正的服务器常常要备份不少的读写硬盘进行更换,成本是很是高的.
第2步:使用命令myisampack命令进行压缩,命令的格式和机制以下,压缩必须压缩MYI索引文件,而不能直接压缩MYD文件,语法格式以下:
myisampack [数据表的索引文件全名]
执行以下:
执行压缩必须在/var/lib/mysql/test目录下进行,回车就会进行压缩优化,时间有长有短,根据设备而定,出现如下界面表明正在进行压缩优化:
若是压缩完成后就会出现如下界面:
第3步:压缩完成,咱们观察压缩的结果以下所示:
咱们发觉tbl_yes.MYI文件被咱们压缩坏了,由于它有原来的684M变成了1k,所以该文没法使用,所以数据也没法正常的读取了,所以出现这个问题,咱们就须要重建索引文件,凡是通过压缩优化100%的可能性都是压坏索引文件,观察压缩的结果咱们发觉其实mysql官方提示咱们一句这样的话,记得执行myisamchk -rq
第4步:执行myisamchk -rq重建tbl_yes表的索引为文件tbl_yes.MYI
其语法格式以下:
myisamchk -rq [要重建的索引文件名称]
执行命令以下所示:
重建因此完成会从新恢复到shell标志当中,以下图所示:
重建索引以后,其实会发觉索引文件其实依然是有损坏的,由于mysql的开发者为了保证MYD文件的数据完整性,因此对索引文件进行性能的牺牲,其实压缩以后数据库表只能是只读的,不能插入任何的数据这个就是压缩的缺点,可是压缩不须要担忧数据丢失和完整性,由于mysql5.1.73对Myisam压缩进行很是严谨的测试.重建索引的过程好像有点死机的感受,可是不须要过度担忧,由于这属于正常继续耐心等待.
MYD文件被压缩称为了324M,比原来的961M大大的缩减,所以提升网络传输的速度.
压缩优化完成必须刷新表
第5步:数据库的索引文件重建以后,并不表明立刻就可使用,由于这时其实索引文件重建后,没法正常读取压缩后数据,可是咱们可使用刷新表的技术,来让数据库恢复读取功能,语法以下:
mysqladmin -uroot -p登陆密码 flush-table #刷新mysql当中表
mysqladmin -uroot -p123456 flush-table
执行没有返回任何的错误,那么就表明刷新表成功
第5步:登陆数据库当中,从新查询tbl_yes这种表,结果以下:
发觉压缩优化,数据不会丢失,因而接着查询username=itcast的用户
能够正常的查出信息,而且性能上没有受到任何的影响,固然也没有任何的提升,接下来插入一条数据,出现结果以下:
发觉压缩优化代价就是致使压缩后表是只读的状态,若是咱们须要继续对tbl_yes这种表进行数据的插入,那么咱们应该怎么办呢?答案:解压当前表
注意一个问题:在压缩优化层面,有一句俗语叫作解铃还须系铃人,也就说谁进行压缩谁就负责解压,为何呢?由于数据其实在现实开发当中通常是由总部进行规划和统一的,分部不能随意插入数据,分部只能读取总部插入的数据,所以压缩优化就被运用在37wan这个场景
若是一张表进行了压缩,那么这张表就只能是只读的,若是须要该表可以从新进行写入的操做,那么就必须使用MyISAM的解压机制.
MyISAM的表解压的详细步骤以下:
第1步:一样须要找到要进行解压的表,而后使用命令: myisamchk --unpack
进行解压操做,若是你忘记了这个命令,咱们可使用man myisamchk来进行查看
发觉有一个这样的选项:
第2步:使用命令以下:
myisamchk --unpack [索引文件名称],执行效果以下:
解压完成后,会出现如下界面:
文件解压后的变化以下:
其实解压也没法恢复到没有压缩的数据状态,文件依然有所损坏的,包括MYD文件也是有所损坏的但不影响任何的操做
第3步(建议步骤):解压完成后,一样不要立刻进行数据的插入,由于若是这时进行数据的插入,可能会为表的后续发展产生一些bug,建议也是解压后进行刷新恢复以后再进行插入.其实这一步不是必须的.执行命令:mysqladmin -uroot -p123456 flush-table
刷新以后,必需要退出mysql的登陆而后再从新登陆
第4步:登陆mysql数据进行数据插入和查询操做,结果以下:
explain是一个Mysql性能显示的工具,它显示了MySQL如何使用索引来处理select语句以及链接表。能够帮助选择更好的索引和写出更优化的查询语句。在开发当中咱们通常用explain来查看索引的使用状况,explain你能够把它理解成为一个查看索引使用状况的工具,但官方对它的定义是explain是一个mysql执行计划(ex=execute),不过这种概念的东西不须要过度的纠结,反正你知道有这么一回事就能够了。
语法规则:explain [select 语句]
执行explain select * from tbl_no where username='itcast' 结果以下:
explain执行计划最重要的选项:
比对explain扫描tbl_yes和tbl_no的结果你会发现其实只要使用索引,那么速度就会很快,并且只要 使用到索引那么就必定不会是全表扫描all的方式,而且扫描的记录行数也大大缩减,所以这个就是为何tbl_yes比tbl_no快的主要缘由,关键一点就是tbl_yes有使用到索引.
数据库的索引其实就好像书本的目录同样,假设你拿一本新华字典来查一个字,若是新华字典的拼音字母的目录不见了,笔画部首的目录被撕掉了,这时你去找这个字你就慢了。但若是从新把这个目录给你,你的查找这个字的速度确定快了不少。索引就至关于这个目录的做用,它能提升select语句查找记录的速度。
在Mysql当中尽管索引查找的速度很是快,然而Mysql的任何一种优化都是须要付出必定代价的,添加索引会占据不少的磁盘的空间,也会下降写操做(delete , update , insert)语句的效率。其实索引咱们很早就接触过,主键就是一种索引。主键也是全部索引当中最高效率的。
在数据库当中,索引优化有一个原则:使用上索引就必定会快,而且使用上索引就不会是ALL
在Mysql的经常使用引擎Innodb和MyISAM当中它们的索引结构是一种叫Btree的类型,由于它们是根据一种叫“二叉树”的算法建立出来的。在Mysql当中常见的索引使用有4种,分别为:
主键索引( Primary Key )
普通索引( Key )
惟一性索引(Unique)
全文索引(FullText):这个索引其实被sphinx取代了其地位
特殊的索引有1种:前缀索引
1.语法规则:show index from [表名称]
使用命令: show index from tbl_yes
primary是一个主键索引,它做用在id字段中
uname的普通索引,它做用在username字段中
2.语法规则:show create table from [表名称]
使用命令:show create table tbl_yes
以上方法实际上是经过查看建表的结构来查看索引的相关信息
主键索引的原则和场景:
在开发当中咱们每每须要对一些重复性的数据进行区分,那么这时咱们就须要使用主键索引,主键索引既不能为null,也不能重复,更不能为空字符串。在id字段中出现最多,一般还会配合自增加一块儿使用,主键索引也是全部索引当中查询速度最快的索引。
代码详细请参考:code/pk1.sql
语法规则:primary key关键字
插入一些数据测试主键:
使用explain执行计划查看主键是否会被使用上:
使用命令explain select * from pk1 where id=2;和explain select * from pk1 where name='jimmy2';进行对比,结果以下所示:
代码详细请参考:code/pk2.sql
语法规则:alter table 表名 add primary key(字段名称)
执行结果以下:
有时候咱们在建立主键索引的时候,遇到id字段咱们还须要配合设置
整型数据类型的自增加,这时可使用如下语法在已有的表中进行创建
语法规则:Alter table 表名 modify 字段名 字段类型 auto_increment
执行后,效果以下:
代码详细请参考:code/pk3.sql
语法规则:Alter table 表名 drop primary key;
主键删除的详细步骤:
1)主键含有自动增加的特性,须要首先删除自增加的属性,不然就会报错,以下图所示:
执行效果以下:
2)使用Alter table语句修改去除主键字段的自动增加属性,以下图所示:
执行结果以下:
3)使用删除主键的语法规则对主键进行删除.
执行结果:
惟一索引的原则和场景:
在开发当中,有时咱们在网站使用用户名进行注册须要对用户进行惟一性约束,这时惟一性索引就能够起到约束的做用,同时惟一索引也能提升数据查找的速度,所以惟一性索引在开发中使用十分普遍。
代码详细请参考:code/unique1.sql
语法规则:create unique index 索引的名称 on 表名(字段名称)
执行效果以下:
插入一些数据测试惟一索引的约束性:
添加一个username为tommy的数据进行测试,效果和步骤以下:
第1次插入:
第2次插入:
以上例子给咱们的启示是能够在注册用户的使用多用惟一性因此进行惟一约束。
使用explain执行计划查看惟一性索引是否会被使用上:
执行命令:
代码详细请参考:code/unique2.sql
语法规则: alter table 表名 drop index 索引的名称
执行结果以下:
代码详细请参考:code/unique3.sql
1.在惟一索引当中,null是能够重复的
若是重复插入null值结果以下:
发觉惟一性索引对NULL值不起任何的约束做用,这个是惟一性索引的缺点
2.在惟一索引当中空字符串是不能重复的
重复插入空字符串进行测试的结果以下:
发觉以上惟一性索引的特性后,咱们能够把users表修改为为如下形式,把惟一性索引在该应用场合中使用主键进行替代,查看效果:
执行结果以下:
面试题:惟一索引和主键的区别是什么?
惟一性索引能够插入NULL值,但对NULL不起任何的约束做用,惟一性因此对空串能够插入一次但对空串起惟一性约束做用,主键不能够插入NULL值,空串也能够插入一次而且起惟一性的约束做用,但主键多用于id列,通常是用int的形式比较多,因此在注册的时候,咱们能够常使用使用惟一索引而省略id的主键索引,以上只是一个参考而不是一个标准.
普通索引的原则和场景:
在开发当中,若是咱们仅仅是为了提高查询的效率但不须要用到任何的约束性行为,那么就可使用普通索引
代码详细请参考:code/normal.sql
建立表和数据以下:
若是这时不对cake_name字段进行索引的建立,那么就会产生以下explain执行结果:
发觉用户若是按蛋糕名称进行搜索,那么就会产生全表扫描,整个效率就太差了。可是咱们又必须不能对cake_name进行惟一索引的约束,这时普通索引的应用场景就出现了。
语法规则:create index 索引名称 on 表名称(字段名称)
执行效果以下:
在表具有数据记录后再建立其实对表的数据发生任何的改变,效果以下:
查看建表的结构以下:
使用explain执行计划查看普通索引是否会被使用上:
查询tbl_yes的表结构以下:
创建普通索引就算数据有5千多万条查询的速度依然能够很快,只要索引能够被使用上便可
语法规则: alter table 表名 drop index 索引的名称
执行结果以下:
代码详细请参考:code/like.sql
若是咱们须要查看articles_like表中title字段含有mysql关键字的数据记录,那么咱们能够建立如下的实验步骤:
第1步:创建articles_like表,而且把title字段设置为普通索引
第2步:为articles_like表插入一些测试数据
执行结果以下:
第3步:咱们使用如下数据库like语句查询标题中含有mysql关键字的数据库记录
使用命令:select * from articles_like where title like '%mysql%';
执行效果以下:
咱们的title字段是有索引的,是一个普通索引tit,可是这时使用like进行模糊搜索,这个索引是否能够被使用上呢?
第4步:使用explain执行计划查看like语句是否使用到索引
使用命令: explain select * from articles_like where title like '%mysql%';
发觉like语句使用不了索引,缘由就在于在MySql数据库中,若是使用like条件语句当中%
出如今查询关键字以前,那么将没法使用到索引。因此如下状况都是不可能使用到索引的:
①select * from articles_like where title like '%mysql%';
②select * from articles_like where title like '%mysql';
若是把%放在查询关键字以后,那么就有可能使用上索引,可是这个只是可能性比较高罢了,而不是100%可使用上的.
如下状况like有可能用得索引,但搜索出来结果不是你想要的:
使用命令: explain select * from articles_like where title like 'mysql%';
执行结果以下:
若是%号出如今搜索关键字以后,那么like是可使用关键字的,然而查询的结果是会丢失记录的:
可是若是咱们真的须要使用到索引,有必须保证查询结果的完整性,那么咱们应该怎么办呢?
全文索引应运而生.
全文索引是为取代Like而生,然而mysql自带的全文因此不支持中文.通常人会使用sphinx+coreseek词库来代替它,这个主题咱们会在第3天的时候着重讲解
全文索引的原则和场景:
全文索引能很好取代like的查询,且功能比like强大,但MySql自带的全文索引FullText在MySql5.6如下的版本并不支持中文,而MySql5.6的数据库版本使用的用户不多.所以MySql自带的全文索引在真正的大型网站开发当中会被Sphinx这个第3方的工具所取代,但自带的全文索引可使用在一些英文的小型网站当中。
代码详细请参考:code/fulltext.sql
若是咱们须要查看articles表中title或者body字段含有database关键字的数据记录,那么咱们若是咱们要知足以上的要求,就必须使用全文索引
语法规则: fulltext(一个或者多个字段名称)
注意:通常使用fulltext的时候不多使用一个字段做为全文索引,由于使用给一个字段全文索引的意义就失去了
执行结果以下:
执行结果以下:
语法规则:match(全文索引的字段列) against( ‘+关键字’ in boolean mode)
①查看articles表中title或者body字段含有database关键字的数据记录
使用命令:
执行结果以下:
②查看articles表中title或者body字段含有mysql关键字的数据记录
使用命令:
结果以下:
发觉以上的查询没有成功,正常来讲应该查询出6条记录,可是为何一条也查不出来的呢?缘由是全文索引实际上是根据算法生成的因此,支持一种叫布尔查询的模式,所以若是不使用布尔查询那么就有可能查询的结果不许确,所以使用全文索引必须使用布尔查询模式,使用布尔查询模式修改上面的查询语句以下所示:
执行结果以下所示,发觉查询正确了:
咱们发觉全文索引其实能够完成like的功能,可是它会使用到索引吗?
使用explain查看全文索引是否有使用到索引:
执行explain语句那么发觉fulltext索引是能够被用上,也就是说Like之后你能够不要使用了,like是能够彻底使用fulltext来取代的,可是fulltext不支持中文,因此只能应用在英文网站当中,若是但愿使用中文的全文因此必须使用第三方工具sphinx+coreseek
在mysql全部数据查询都是实时的过程,无论一次查询数据是否有找到,那么数据库的编译器都必须在硬盘中作一次数据的查找响应,原理以下所示:
Mysql提供了一个机制,就是开启一个叫Qcache的空间缓存,这个缓存空间存在Mysql编译器内存当中,有一个用户发起了一次请求编译器会判断当前是否已经发起过,若是发起过,那么编译器将不会继续在硬盘当中作出查找的响应,而是把Qcache当中的结果进行返回,若是用户发起的请求是第一次的发起,那么mysql依然会从硬盘当中查找数据,可是同时也会把查找结果保存到Qcache空间当中,准备下一次查询响应,其原理以下所示:
开启Mysql查询缓存就是开启编译器中的Qcache空间,这个空间默认的状况下以字节的大小来计算空间的大小,因此咱们须要使用子字节换算来开启Qcache空间的大小
1k = 1024字节
1M = 1024k = 1024 * 1024字节
若是但愿表示一个64M的字节大小,那么咱们能够换算成为如下形式公式:
64M = 64 *1024 * 1024字节
开启MySql查询缓存的语法格式以下:
set global query_cache_size = 字节大小
需求1:开启64M的查询缓存空间(Qcache),代码以下:
set global query_cache_size = 64 *1024*1024
若是没有开启查询缓存时,使用select语句查询tbl_no的username=itcast的信息记录以下所示:
第1次查询以下,用时17.47sec:
第2次查询以下,用时14.57sec,虽然有所提高,可是并不稳定,也不够理想
这时咱们使用查询缓存机制,开启一个64M的Qcache空间,以下所示:
开启成功后,咱们从新对tbl_no表username=itcast进行查询
第1次查询:因为第1次查询Qcache并无任何的记录,因此mysql会从硬盘中查找
耗时:14.44sec
第2次查询:因为第2次查询时Qcache已经记录当前的查询结果,所以mysql不会去硬盘中查找数据,直接从Qcache当中返回数据,所以耗时接近0秒甚至达到0秒
假设这时咱们换一个查询条件,查询username=itheima的信息以下:
第1次查询:发觉这时又没有缓存的结果,由于这是第1次查询,耗时16.88sec
第2次查询,发觉耗时接近0秒甚至达到0秒,查询缓存的开启就会让第1次查询很慢以后都会很快,因此达到必定的优化过程
查询缓存的缺点是:若是查询缓存的累积空间达到64M的上限,那么mysqld就会自动释放Qcache空间,使得原来缓存消失,而且开启过多的Qcache空间会致使mysql编译器内存空间被占用过多,所以后来有人使用Memcache和redis进行取代,可是若是你的数据不算很是多,那么使用查询缓存是很是值得,由于查询缓存的开启方式和使用方式很是的简单
关闭mysql的查询缓存有两种方法:
1)重启mysqld服务,使用service mysqld restart
2)使用命令: set global query_cache_size = 0 (建议使用该方法)
关闭以后,查询查询username=itcast的信息以下:
发觉查询缓存消失,数据查询从新开始变慢
有时候咱们须要直到这个查询缓存是否已经开启,咱们可使用如下命令进行查看:
show variables like '%query_cache_size%'
若是开启了查询缓存,那么查询结果以下:
在开发当中,有时候咱们但愿可以捕捉到慢操做的相关具体命令,那么这时咱们就须要使用慢查询日志(query_slow_logs),然而慢查询日志不仅是记录select语句的慢操做,其余的语句如:insert update delete若是慢的话也会被日志所记录
慢查询日志有如下重要的函数(命令):
#表示当前MySql的认为慢操做的时间
show variables like 'long_query_time'
mysql默认状况下认为达到10秒钟的操做才算慢,这就与8秒原则相矛盾了,所以咱们须要调整这个long_query_time的时间,根据本身的喜欢认为怎么样才算慢去调整,通常调整为2秒钟
#显示当前MySql的慢查询日志相关选项
show variables like '%slow%';
#显示当前MySql的慢操做总数
show status like 'Slow_queries';
若是但愿开启慢查询日志,咱们就必需要在Mysql配置文件中打开对应的配置选项,Mysql的配置文件存放在/etc/my.cnf当中,使用vim打开/etc/my.cnf
内容以下所示:
咱们须要迅速找到如下几项:
修改以上3项内容以下所示:
保存并退出(:x),而后重启mysqld服务
若是重启没有报错,就表明配置选项设置成功,退出mysql登陆从新登陆,重看相关选项
而后咱们检查配置无误后,咱们到/var/lib/mysql目录下查看,发觉有如下文件:
而后咱们使用一个超过2秒钟的慢查询语句,以下所示:
这时咱们打开/var/lib/mysql/myslow.txt文件查看,使用vim打开
内容以下所示: