MySQL优化自学手册

MySQL优化自学手册
MySQL优化自学手册

/*

* ------------------------------------------------------------------- * |-标题:MySQL优化自学手册

* |-整理: 杨白玉

* |-时间: 2015年9月25日

* ------------------------------------------------------------------- */

mysql优化

前提:数据库性能的优劣直接影响到程序的性能,所以数据库的设计与参数配置至关重要。

数据库优化的方式:

1、数据库设计

2、sql语句的优化

3、数据库参数的配置(扩展数据库的缓存或者数据库的空间)

4、恰当的硬件资源(钱的问题,有钱就能满足)

第一章数据库的设计

一、数据库的设计:

数据库的设计指的就是表的设计。设计要符合三范式(规范的模式),有时我们也需要适当的逆范式;

二、什么是三范式?

第一范式:1NF是对属性(可理解为字段)的原子性约束,要求属性具有原子性,不可再分。第二范式:2NF是对记录的唯一性约束,要求记录有唯一的标识,即实体的唯一性;

第三范式:3NF是对字段冗余的约束,即任何字段不能由其他字段派生出来,要求字段没有冗余,这是可以做到的。

然而,没有冗余的数据库未必是好的数据库,有时候为了提高运行的效率,我们也会使用适当的逆范式,方法就是:增加字段。

一般来说,1NF在关系型数据库中是自动满足的;

2NF通常通过主键自增的唯一性来约束。而且,记录本身也很少会完全一样;

3NF主要是在主从表中,不会出现相同的字段与字段值;

第二章 SQL语句的优化

一、SQL语句优化的步骤:

1、通过show status 命令了解各种sql的执行频率;

2、定位执行效率较低的SQL语句,主要集中在查询语句

3、通过explain分析低效率的sql语句的执行情况

4、确定问题并采取相应的优化措施

二、sql语句有几类?

ddl(数据定义语句)[create alter drop]

dml(数据操作语句)[insert delete update]

select

dtl(数据事物语句)[commit rollback savepoint]

dcl(数据控制语句)[grant revoke]

show status命令

该命令可以显示mysql数据库当前的状态,我们主要重点关注“Com”开头的指令。

1、显示数据库开启本次会话后到目前的信息:

show status like “Com%”; <=> show session status like “Com%”;

2、显示数据库从启动到目前的信息:

Show global status like “Com%”;

说明:通过上述命令,可以很容易的了解到当前的数据库是以插入更新为主还是以查询为主,以及各类sql大致的执行比例是多少。

3、显示连接数据库的次数,如果并发高的话,就需要考虑并发的问题:

show status like “Connections”;

4、mysql服务器工作的时间(单位是秒)

show status like “Uptime”;

5、慢查询

(1)、定位慢查询的次数(默认是10秒)

show status like “Slow_queries”;

(2)、慢查询是我们优化的重点,默认情况下是10s;

show variables like “long_query_time”;

(3)、设置慢查询的时间:

set long_query_time=值;

(4)、查询慢查询的次数:

show status like “slow%”;

分析:如何在项目中,找到慢查询的select语句,mysql数据库支持把慢查询语句,记录到日志中供程序员分析,默认是不启用的;

方法:

进入到mysql安装目录,切换到mysql的bin目录下,使用mysqld.exe启动;

命令:XX>mysqld.exe -show-query-log

知识扩展:如果你的数据库存储引擎是MyISAM的,则当创建一个表后,再磁盘中会生成3个文件:*.frm 记录表结构| *.myd 数据| *.myi 索引

数据库优化方式一:添加索引

1、索引介绍

对于提高数据库的性能,索引是绝佳选择,无需增加硬件、改变程序、调整sql语句,就能达到数据库优化的效果;然而,索引虽然提高了数据的查询效率,但却是以插入、更新、删除的速度为代价的,增加了大量的I/O,具体原因如下:

我们知道,索引是保存在*.myi文件中进行维护的,索引类似字典的目录,在查询的时候可以快速定位,而不需要去逐条查询,这明显加快了查询效率;然而数据库在每次执行增、删、改操作时,*.myi文件对应的每次需要去更新维护索引信息,这无疑就增加了I/O;

2、索引的类型

(1)、主键索引(primary key,一张表只能有一个主键)

(2)、唯一索引(unique,建表的同时设置,是没有效果的,需要建好表后,单独添加该索引)

(3)、普通索引(index)

(4)、全文索引(fulltext,只有myisam存储引擎支持),sphinx+中文分词

(5)、复合索引(多列组合在一起,很少使用;格式:alter table 表名add index 索引名(字段1,

字段2...) )

3、索引的使用方式

3-1-1:添加主键索引:

alter table 表名add primary key(字段);

3-1-2:删除主键索引:

alter table 表名drop primary key;

3-2-1:创建“唯一索引、普通索引、全文索引”的方式:

carete [unique][fulltext][index] 索引名on 表名(字段);

alter table 表名add [unique][fulltext][index] 索引名(字段);

3-2-2:删除“唯一索引、普通索引、全文索引”的方式:

drop [unique][fulltext][index] 索引名on 表名;

alter table 表名drop [unique][fulltext][index] 索引名;

3-3-1:查询索引

show index from 表名;

show keys form 表名;

desc 表名;

4、使用索引的注意事项

4-1:对于使用like的查询,查询条件如果是”%查询关键词”不会使用到索引;

4-2:如果查询条件中有or,即使其中有条件带索引,其实也不会使用;

4-3:对于复合索引,只要查询条件使用了最左边的索引列,索引一般就会被使用;如果查询条件的索引不是使用的最左边的索引列,则不会使用索引;

4-4:如果字段的类型是字符串,那么一定要在查询条件中把查询关键词用引号引起来,否则不会使用到索引。

4-5:如果mysql估计使用全表扫描要比索引更快,则自动忽略不适用索引;

5、如何检测索引是否有效

命令:show status like “handler_read%”;

返回参数说明:

handler_read_key :这个值越高越好,越高表示使用索引查询到的次数越多;

handler_read_rnd_next :这个值越高,说明查询效率越低;

6、explain分析语句

格式:explain 查询语句\G

返回结果:

id SQL语句会使用的索引

select_type SIMPLE:普通查询

table 表名

type ALL:全表扫描,性能最次;system:系统表;const:表最多有一个匹配行

possible_keys 可能用到的索引类型(其中NULL表示无索引类型)

key 实际用到的索引类型(其中NULL表示无索引)

key_len 索引的长度(其中NULL表示索引长度为零,其实就是没有索引)

ref 无实际意义

rows 本次查询检索了多少条记录

Extra 查询细节信息

7、myisam和innodb的区别是什么?

(1)、myisam不支持外键,innodb支持;

(2)、myisam不支持事务,innodb支持;

(3)、对数据的保存方式不同:如果存储引擎是myisam,则创建一张表的时候,分别生成3个文件:*.frm | *.myd | *.myi;如果存储引擎是innodb,则创建一张表的时候,只生成一个文件:*.frm,而数据则存储在xxx/data/ibdata1文件中;

(4)、myisam存储引擎,在数据删除后,*.MYD文件大小并不会变小(即空间不会自动回收),随着*.MYD文件无限膨胀,最终结果会导致磁盘开销达到峰值,数据无法继续添加,这对于QQ等这等类大批量增删操作频繁的软件,很要命;所以,对于使用myisam存储引擎的数据

表,需要定期使用指令:“optimize table 表名;”进行空间回收;

(5)、myisam的查询速度要比innodb更快;

8、对于使用索引后的大批量插入数据,需要进行如下操作:

8-1:如果存储引擎是myisam:

//第一步:禁用索引,防止随着数据一条一条录入,而索引也一条一条添加;

alter table 表名display keys;

//第二步:大批量增加数据

loading data;

//第三步:启用索引,此时索引会自动给新增的数据添加索引

alter table 表名enable keys;

8-2:如果存储引擎是innodb:

//第一步:将需要导入的数据按照主键排序;

//第二步:关闭唯一性校验;

set unique_checks=0;

//第三步:关闭自动提交;

set autocommit=0

◆数据库优化方式二:group by语句中禁用order by

主要针对group by语句;

默认情况下,mysql对所有的group by col1,col2…都会进行进行文件排序,这个与在查询中使用order by col1,col2…类似。这明显是影响查询效率的,所以我们需要在使用group by 语句的同时,使用order by null禁止排序;

格式如下:select * from 表group by 字段order by null;

◆数据库优化方法三:尽量使用join查询代替子查询

因为使用join查询,mysql不需要在内存中创建临时表。

◆数据库优化方法四:

如果想在or的查询语句中利用索引,那么在or的每个条件都必须增加索引,否则不会使用到索引;

数据库优化方法五:字段类型、长度尽量使用恰当的类型、确定的存储数值,以保证结果的准确性;

比如:md5加密后的数据,长度为32;所以在保存用户密码的时候,只用char优于varchar;

第三章表的垂直分割和水平分割

一、水平分割

假设一张表中有100亿条QQ账号记录,我们可以把这一张表划分成100张,这100张表的字段完全一样。表然后每张表中只存储1亿条记录,这100张表的表名格式为:表名0、表名1、表名2…表名99;

说明:

表名后边的0、1、2…99这些标号是来源于:当前记录的ID%100来计算得知,范围为:0~99;

然后在添加记录的时候,根据当前记录的ID%100得到的值来决定往哪张表中添加记录;读取的时候也是同理;

原理图如下:

二、垂直分割:

主要方式:把一张表的字段分成几张表来保存;垂直分割比较常见,不再赘述;

第四章读写分离技术

读写分离的原理:

目的:给大型网站减轻查询压力;

做法及原理:在服务器端安装amoeba服务器(新浪自己做的),这个工具可以自动判断sql语句是dml语句还是select语句;如果是dml语句,自动操作master主数据库,然后主数据库会通过mysql proxy把数据自动同步到slave从数据库;如果是select语句,就自动找一个当前压力比较小的slave从数据库进行查询操作,然后将结果返回,这就是读写分离技术;

原理图:

amoeba的汉语读法:爱魔棒

另外需要注意的是:在数据库读写分离技术中,数据库集群都是单独装到一太服务器上的;

知识扩展:Mysql.ini的有效配置文件内容:

sql语句(mysql优化)绝对经典

sql语句(mysql优化)绝对经典 误区1:count(1)和count(primary_key) 优于count(*) 很多人为了统计记录条数,就使用count(1) 和count(primary_key) 而不是count(*) ,他们认为这样性能更好,其实这是一个误区。对于有些场景,这样做可能性能会更差,应为数据库对count(*) 计数操作做了一些特别的优化。 误区2:count(column) 和count(*) 是一样的 这个误区甚至在很多的资深工程师或者是DBA 中都普遍存在,很多人都会认为这是理所当然的。实际上,count(column) 和count(*) 是一个完全不一样的操作,所代表的意义也完全不一样。count(column) 是表示结果集中有多少个column字段不为空的记录,count(*) 是表示整个结果集有多少条记录 误区3:select a,b from … 比select a,b,c from …可以让数据库访问更少的数据量 这个误区主要存在于大量的开发人员中,主要原因是对数据库的存储原理不是太了解。实际上,大多数关系型数据库都是按照行(row)的方式存储,而数据存取操作都是以一个固定大小的IO单元(被称作block 或者page)为单位,一般为4KB,8KB… 大多数时候,每个IO单元中存储了多行,每行都是存储了该行的所有字段(lob等特殊类型字段除外)。 所以,我们是取一个字段还是多个字段,实际上数据库在表中需要访问的数据量其实是一样的。当然,也有例外情况,那就是我们的这个查询在索引中就可以完成,也就是说当只取a,b两个字段的时候,不需要回表,而c这个字段不在使用的索引中,需要回表取得其数据。在这样的情况下,二者的IO量会有较大差异。(覆盖索引) 误区4:order by 一定需要排序操作 我们知道索引数据实际上是有序的,如果我们的需要的数据和某个索引的顺序一致,而且我们的查询又通过这个索引来执行,那么数据库一般会省略排序操作,而直接将数据返回,因为数据库知道数据已经满足我们的排序需求了。实际上,利用索引来优化有排序需求的SQL,是一个非常重要的优化手段。延伸阅读:MySQL ORDER BY 的实现分析,MySQL 中GROUP BY 基本实现原理以及MySQL DISTINCT 的基本实现原理。(order by null)

优化mysql数据库性能

为了提高性能建议作如下优化修改: 优化mysql数据库性能的参数: (1)、max_connections: 允许的同时客户的数量。增加该值增加mysqld 要求的文件描述符的数量。这个数字应该增加,否则,你将经常看到too many connections错误。默认数值是16384,请根据实际情况设置此参数。 (2)、key_buffer_size: 索引块是缓冲的并且被所有的线程共享。key_buffer_size是用于索引块的缓冲区大小,增加它可得到更好处理的索引(对所有读和多重写),到你能负担得起那样多。如果你使它太大,系统将开始换页并且真的变慢了。默认数值是10M,请根据实际情况设置此参数。 (3)、sort_buffer: 每个需要进行排序的线程分配该大小的一个缓冲区。增加这值加速order by或group by操作。默认数值是256K,请根据实际情况设置此参数。 4)、table_cache: 为所有线程打开表的数量。增加该值能增加mysqld要求的文件描述符的数量。mysql对每个唯一打开的表需要2个文件描述符。默认数值是256,,请根据实际情况设置此参数。 (5)、thread_cache_size: 可以复用的保存在中的线程的数量。如果有,新的线程从缓存中取得,当断开连接的时候如果有空间,客户的线置在缓存中。如果有很多新的线程,为了提高性能修改这个变量值。通过比较connections 和threads_created 状态的变量,可以看到这个变量的作用。默认数值是8,请根据实际情况设置此参数。 注:以上参数的调整可以通过修改C:\AppServ\MySQL\my.ini 文件并重启mysql 实现。这是一个比较谨慎的工作,上面的结果只供参考,请根据具体主机的硬件情况(特别是内存大小)进一步修改。 优化配置文件: C:\zxin10\Was\tomcat\conf\ server.xml (6)、在server.xml中修改标红相关参数。 (7)、

mysql服务性能优化my_cnf配置说明详解16G内存

mysql服务性能优化—https://www.360docs.net/doc/165722271.html,f配置说明详解 (16G内存) MYSQL服务器https://www.360docs.net/doc/165722271.html,f配置文档详解 硬件:内存16G [client] port = 3306 socket = /data/3306/mysql.sock [mysql] no-auto-rehash [mysqld] user = mysql port = 3306 socket = /data/3306/mysql.sock basedir = /usr/local/mysql datadir = /data/3306/data open_files_limit = 10240 back_log = 600 #在MYSQL暂时停止响应新请求之前,短时间内的多少个请求可以被存在堆栈中。如果系统在短时间内有很多连接,则需要增大该参数的值,该参数值指定到来的TCP/IP连接的监听队列的大小。默认值50。 max_connections = 3000 #MySQL允许最大的进程连接数,如果经常出现Too Many Connections的错误提示,则需要增大此值。 max_connect_errors = 6000 #设置每个主机的连接请求异常中断的最大次数,当超过该次数,MYSQL服务器将禁止host 的连接请求,直到mysql服务器重启或通过flush hosts命令清空此host的相关信息。 table_cache = 614 #指示表调整缓冲区大小。# table_cache 参数设置表高速缓存的数目。每个连接进来,都会至少打开一个表缓存。#因此, table_cache 的大小应与 max_connections 的设置有关。例如,对于 200 个#并行运行的连接,应该让表的缓存至少有 200 × N ,这里 N 是应用可以执行的查询#的一个联接中表的最大数量。此外,还需要为临时表和文件保留一些额外的文件描述符。 # 当 Mysql 访问一个表时,如果该表在缓存中已经被打开,则可以直接访问缓存;如果#还

MySQL5.1性能优化方案

MySQL5.1性能优化方案 1.平台数据库 1.1.操作系统 Red Hat Enterprise Linux Server release 5.4 (Tikanga) ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped 32位Linux服务器,单独作为MySQL服务器使用。 1.2.M ySQL 系统使用的是MySQL5.1,最新的MySQL5.5较之老版本有了大幅改进。主要体现在以下几个方面: 1)默认存储引擎更改为InnoDB InnoDB作为成熟、高效的事务引擎,目前已经广泛使用,但MySQL5.1之前的版本默认引擎均为MyISAM,此次MySQL5.5终于将默认数据库存储引擎改为InnoDB,并且引进了Innodb plugin 1.0.7。此次更新对数据库的好处是显而易见的:InnoDB的数据恢复时间从过去的一个甚至几个小时,缩短到几分钟(InnoDB plugin 1.0.7,InnoDB plugin 1.1,恢复时采用红-黑树)。InnoDB Plugin 支持数据压缩存储,节约存储,提高内存命中率,并且支持adaptive flush checkpoint, 可以在某些场合避免数据库出现突发性能瓶颈。 Multi Rollback Segments:原来InnoDB只有一个Segment,同时只支持1023的并发。现已扩充到128个Segments,从而解决了高并发的限制。 2)多核性能提升

mysql性能优化-慢查询分析、优化索引和配置

mysql性能优化-慢查询分析、优化索引和配置目录 一、优化概述 二、查询与索引优化分析 1性能瓶颈定位 Show命令 慢查询日志 explain分析查询 profiling分析查询 2索引及查询优化 三、配置优化 1) max_connections 2) back_log 3) interactive_timeout 4) key_buffer_size 5) query_cache_size 6) record_buffer_size 7) read_rnd_buffer_size 8) sort_buffer_size 9) join_buffer_size 10) table_cache 11) max_heap_table_size 12) tmp_table_size

13) thread_cache_size 14) thread_concurrency 15) wait_timeout 一、优化概述 MySQL数据库是常见的两个瓶颈是CPU和I/O的瓶颈,CPU在饱和的时候一般发生在数据装入内存或从磁盘上读取数据时候。磁盘I/O瓶颈发生在装入数据远大于内存容量的时候,如果应用分布在网络上,那么查询量相当大的时候那么平瓶颈就会出现在网络上,我们可以用mpstat, iostat, sar和vmstat来查看系统的性能状态。 除了服务器硬件的性能瓶颈,对于MySQL系统本身,我们可以使用工具来优化数据库的性能,通常有三种:使用索引,使用EXPLAIN分析查询以及调整MySQL的内部配置。 二、查询与索引优化分析 在优化MySQL时,通常需要对数据库进行分析,常见的分析手段有慢查询日志,EXPLAIN 分析查询,profiling分析以及show命令查询系统状态及系统变量,通过定位分析性能的瓶颈,才能更好的优化数据库系统的性能。 1 性能瓶颈定位 Show命令 我们可以通过show命令查看MySQL状态及变量,找到系统的瓶颈: Mysql> show status ——显示状态信息(扩展show status like ‘XXX’) Mysql> show variables ——显示系统变量(扩展show variables like ‘XXX’) Mysql> show innodb status ——显示InnoDB存储引擎的状态 Mysql> show processlist ——查看当前SQL执行,包括执行状态、是否锁表等

MySQL大数据量的查询提高性能优化

最近一段时间参与的项目要操作百万级数据量的数据,普通SQL查询效率呈直线下降,而且如果where中的查询条件较多时,其查询速度简直无法容忍。之前数据量小的时候,查询语句的好坏不会对执行时间有什么明显的影响,所以忽略了许多细节性的问题。 经测试对一个包含400多万条记录的表执行一条件查询,其查询时间竟然高达40几秒,相信这么高的查询延时,任何用户都会抓狂。因此如何提高sql语句查询效率,显得十分重要。以下是结合网上流传比较广泛的几个查询语句优化方法: 基本原则:数据量大的时候,应尽量避免全表扫描,应考虑在where 及order by 涉及的列上建立索引,建索引可以大大加快数据的检索速度。但是,有些情况索引是不会起效的,因此,需要下面的做法进行优化: 1、应尽量避免在where 子句中使用!=或<>操作符,否则将引擎放弃使用索引而进行全表扫描。 2、应尽量避免在where 子句中对字段进行null 值判断,否则将导致引擎放弃使用索引而进行全表扫描,如: select id from t where num is null 可以在num上设置默认值0,确保表中num列没有null值,然后这样查询: select id from t where num=0 3、尽量避免在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 4、下面的查询也将导致全表扫描:

千万级的mysql数据库与优化方法

千万级的mysql数据库与优化方法 1.对查询进行优化,应尽量避免全表扫描,首先应考虑在where 及order by 涉及的列上建立索引。 2.应尽量避免在where 子句中对字段进行null 值判断,否则将导致引擎放弃使用索引而进行全表扫描,如: Sql代码 可以在num上设置默认值0,确保表中num列没有null值,然后这样查询: Sql代码 3.应尽量避免在where 子句中使用!=或<>操作符,否则将引擎放弃使用索引而进行全表扫描。 4.应尽量避免在where 子句中使用or 来连接条件,否则将导致引擎放弃使用索引而进行全表扫描,如:Sql代码 可以这样查询: Sql代码 5.in 和not in 也要慎用,否则会导致全表扫描,如: 对于连续的数值,能用between 就不要用in 了: 6.下面的查询也将导致全表扫描: Sql代码

若要提高效率,可以考虑全文检索。 7.如果在where 子句中使用参数,也会导致全表扫描。因为SQL只有在运行时才会解析局部变量,但优化程序不能将访问计划的选择推迟到运行时;它必须在编译时进行选择。然而,如果在编译时建立访问计划,变量的值还是未知的,因而无法作为索引选择的输入项。如下面语句将进行全表扫描: Sql代码 可以改为强制查询使用索引: 8.应尽量避免在where 子句中对字段进行表达式操作,这将导致引擎放弃使用索引而进行全表扫描。如: 应改为: 9.应尽量避免在where子句中对字段进行函数操作,这将导致引擎放弃使用索引而进行全表扫描。如:Sql代码 应改为: 10.不要在where 子句中的“=”左边进行函数、算术运算或其他表达式运算,否则系统将可能无法正确使用索引。 11.在使用索引字段作为条件时,如果该索引是复合索引,那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引,否则该索引将不会被使用,并且应尽可能的让字段顺序与索引顺序相一致。 12.不要写一些没有意义的查询,如需要生成一个空表结构:

Mysql千万级别数据优化方案总结

Mysql千万级别数据优化方案 目录 目录 (1) 一、目的与意义 (2) 1)说明 (2) 二、解决思路与根据(本测试表中数据在千万级别) (2) 1)建立索引 (2) 2)数据体现(主键非索引,实际测试结果其中fid建立索引) (2) 3)MySQL分页原理 (2) 4)经过实际测试当对表所有列查询时 (2) 三、总结 (3) 1)获得分页数据 (3) 2)获得总页数:创建表记录大数据表中总数通过触发器来维护 (3)

一、目的与意义 1)说明 在MySql单表中数据达到千万级别时数据的分页查询结果时间过长,对此进行优达 到最优效果,也就是时间最短;(此统计利用的jdbc连接,其中fid为该表的主键;) 二、解决思路与根据(本测试表中数据在千万级别) 1)建立索引 优点:当表中有大量记录时,若要对表进行查询,第一种搜索信息方式是全表搜 索,是将所有记录一一取出,和查询条件进行一一对比,然后返回满足条件的记 录,这样做会消耗大量数据库系统时间,并造成大量磁盘I/O操作;第二种就是 在表中建立索引,然后在索引中找到符合查询条件的索引值,最后通过保存在索 引中的ROWID(相当于页码)快速找到表中对应的记录。 缺点:当对表中的数据进行增加、删除和修改的时候,索引也要动态的维护,降 低了数据的维护速度。 2)数据体现(主键非索引,实际测试结果其中fid建立索引) 未创建索引:SELECT fid from t_history_data LIMIT 8000000,10结果:13.396s 创建索引:SELECT fid from t_history_data LIMIT 8000000,10结果:2.896s select*fromt_history_datawherefidin (任意十条数据的id )结果:0.141s 首先通过分页得到分页的数据的ID,将ID拼接成字符串利用SQL语句 select * from table where ID in (ID字符串)此语句受数据量大小的影响比较小 (如上测试); 3)MySQL分页原理 MySQL的limit工作原理就是先读取n条记录,然后抛弃前n条,读m条想要 的,所以n越大,性能会越差。 优化前SQL: SELECT * FROM v_history_data LIMIT 5000000, 1010.961s 优化后SQL: SELECT * FROM v_history_data INNER JOIN (SELECT fid FROM t_history_data LIMIT 5000000, 10) a USING (fid)1.943s 分别在于,优化前的SQL需要更多I/O浪费,因为先读索引,再读数据,然后 抛弃无需的行。而优化后的SQL(子查询那条)只读索引(Cover index)就可以了, 然后通过member_id读取需要的列 4)经过实际测试当对表所有列查询时 select * from table 会比select (所有列名)from table 快些(以查询8000000

Mysql性能优化

MySQL性能优化 性能优化是通过某些有效的方法来提高MySQL的运行速度,减少占用的磁盘空间。性能优化包含很多方面,例如优化查询速度,优化更新速度和优化MySQL服务器等。本文介绍方法的主要有: 优化查询 优化数据库结构 优化MySQL服务器 数据库管理人员可以使用SHOW STATUS语句来查询MySQL数据库的性能。语法:SHOW STATUE LIKE ‘value’;其中value参数是常用的几个统计参数。 Connections:连接MySQL服务器的次数 Uptime:MySQL服务器的上线时间; Slow_queries:慢查询的次数; Com_select:查询操做的次数; Com_insert:插入操作的次数; Com_delete:删除操作的次数; Com_update:更新操作的次数; 1优化查询 查询操作是最频繁的操作,提高了查询速度可以有效提高MySQL 数据库的性能。 首先要对查询语句进行分析,分析查询语句的命令是EXPLAIN语句和DESCRIBE语句。比如 EXPLAIN SELECT * FROM student \G; 索引可以快速定位表中的某条记录。使用索引也可以提高数据库查

询的速度,从而提高数据库的性能。如果不使用索引,查询语句将 表中的所有字段。这样查询的速度会很慢。如果使用了索引,查询语句只会查询索引字段。这样就减少查询的记录数,达到提高查询效率的目的。 现在看一个查询语句中没有索引的使用情况: SELECT * FROM student WHERE name = ‘张三’;这样会对student表中的所有数据都查询一下,对比一下name的字段是否是张三。 然后我们在name字段上建立一个名为index_name的索引:CREATE INDEX index_name ON student(name); 现在name字段上面已经有索引了,再进行该select语句查询的速度就非常快了,不需要遍历整个表。 但是有些时候即使查询时使用的是索引,但索引并没有起作用。比如使用了LIKE关键字进行查询时,如果匹配字符串的第一个字符 为‘%’,索引不会被使用。如果‘%’不是在第一个位置,索引就会被使用。 另一种情况是在表的多个字段上创建一个索引,比如 CREATE INDEX index ON student(birth,department);这样只有查询语句条件中使用字段name时,索引才会被用到。因为name字段是多列索引的第一个字段,只有查询条件中使用了name字段才会使索引index起作用。 2优化子查询 很多查询中需要使用子查询。子查询可以使查询语句很灵活,但子查询的执行效率不高。MySQL需要为内层查询语句的查询结果建立一个临时表。然后外层查询语句在临时表中查询记录。查询完毕后,MySQL需要插销这些临时表。所以在MySQL中可以使用连接查询来代替子查询。连接查询不需要建立临时表,其速度比子查询要快。

优化MySQL数据库性能的几个好方法

1、选取最适用的字段属性 MySQL可以很好的支持大数据量的存取,但是一般说来,数据库中的表越小,在它上面执行的查询也就会越快。因此,在创建表的时候,为了获得更好的性能,我们可以将表中字段的宽度设得尽可能小。例如,在定义邮政编码这个字段时,如果将其设置为CHAR(255),显然给数据库增加了不必要的空间,甚至使用VARCHAR这种类型也是多余的,因为CHAR(6)就可以很好的完成任务了。同样的,如果可以的话,我们应该使用MEDIUMINT而不是BIGIN来定义整型字段。 另外一个提高效率的方法是在可能的情况下,应该尽量把字段设置为NOT NULL,这样在将来执行查询的时候,数据库不用去比较NULL值。 对于某些文本字段,例如“省份”或者“性别”,我们可以将它们定义为ENUM类型。因为在MySQL中,ENUM类型被当作数值型数据来处理,而数值型数据被处理起来的速度要比文本类型快得多。这样,我们又可以提高数据库的性能。 2、使用连接(JOIN)来代替子查询(Sub-Queries) MySQL从4.1开始支持SQL的子查询。这个技术可以使用SELECT语句来创建一个单列的查询结果,然后把这个结果作为过滤条件用在另一个查询中。例如,我们要将客户基本信息表中没有任何订单的客户删除掉,就可以利用子查询先从销售信息表中将所有发出订单的客户ID取出来,然后将结果传递给主查询,如下所示: DELETE FROM customerinfo WHERE CustomerID NOT in (SELECT CustomerID FROM salesinfo ) 使用子查询可以一次性的完成很多逻辑上需要多个步骤才能完成的SQL操作,同时也可以避免事务或者表锁死,并且写起来也很容易。但是,有些情况下,子查询可以被更有效率的连接(JOIN).. 替代。例如,假设我们要将所有没有订单记录的用户取出来,可以用下面这个查询完成:

【黑马程序员】MySQL的性能调优一

【黑马程序员】MySQL的性能调优一 什么是MySQL,怎么安装,怎么使用,我这里不做说明了。 一、MySQL 与其他数据库的简单比较 1.1性能比较 性能方面,一直是MySQL 引以为自豪的一个特点。在权威的第三方评测机构多次测试较量各种数据库TPCC 值的过程中,MySQL 一直都有非常优异的表现,而且在其他所有商用的通用数据库管理系统中,仅仅只有Oracle 数据库能够与其一较高下。至于各种数据库详细的性能数据,我这里就不便记录,大家完全可以通过网上第三方评测机构公布的数据了解具体细节信息。 MySQL 一直以来奉行一个原则,那就是在保证足够的稳定性的前提下,尽可能的提高自身的处理能力。也就是说,在性能和功能方面,MySQL 第一考虑的要素主要还是性能,MySQL希望自己是一个在满足客户99%的功能需求的前提下,花掉剩下的大部分精力来性能努力,而不是希望自己是成为一个比其他任何数据库的功能都要强大的数据库产品。 1.2可靠性 关于可靠性的比较,并没有太多详细的评测比较数据,但是从目前业界的交流中可以了解到,几大商业厂商的数据库的可靠性肯定是没有太多值得怀疑的。但是做为开源数据库管理系统的代表,MySQL 也有非常优异的表现,而并不是像有些人心中所怀疑的那样,因为不是商业厂商所提供,就会不够稳定不够健壮。从当前最火的Facebook 这样大型的网站都是使用MySQL 数据库,就可以看出,MySQL 在稳定可靠性方面,并不会

比我们的商业厂商的产品有太多逊色。而且排在全球前10 位的大型网站里面,大部分都有部分业务是运行在MySQL数据库环境上,如Yahoo,Google 等。 总的来说,MySQL 数据库在发展过程中一直有自己的三个原则:简单、高效、可靠。从上面的简单比较中,我们也可以看出,在MySQL 自己的所有三个原则上面,没有哪一项是做得不好的。而且,虽然功能并不是MySQL 自身所追求的三个原则之一,但是考虑到当前用户量的急剧增长,用户需求越来越越多样化,MySQL 也不得不在功能方面做出大量的努力,来不断满足客户的新需求。比如最近版本中出现的Eent Scheduler (类似于Oracle 的Job 功能),Partition 功能,自主研发的Maria 存储引擎在功能方面的扩展,Falcon 存储引擎对事务的支持等等,都证明了MySQL 在功能方面也开始了不懈的努力。 任何一种产品,都不可能是完美的,也不可能适用于所有用户。我们只有衡量了每一种产品的各种特性之后,从中选择出一种最适合于自身的产品。 二、MySQL 的主要适用场景 据说目前MySQL 用户已经达千万级别了,其中不乏企业级用户。可以说是目前最为流行的开源数据库管理系统软件了。任何产品都不可能是万能的,也不可能适用于所有的应用场景。 那么MySQL 到底在什么场景下适用什么场景下不适用呢? 1、Web 网站系统 Web 站点,是MySQL 最大的客户群,也是MySQL 发展史上最为重要的支撑力量,这一点在最开始的MySQL Server 简介部分就已经说明过。 MySQL 之所以能成为Web 站点开发者们最青睐的数据库管理系统,是因为

MySQL数据库性能(SQL)优化方案-期末论文

高级数据库技术——期末论文 基于SQL查询的MySQL数据库性能优化研究 :XX 学号:2014XXXXX 学院:计算机学院

摘要: 查询是数据库系统中最基本也是最常用的一种操作,是否具有较快的执行速度,已成为数据库用户和设计者极其关心的问题。在研究开源数据库管理系统MySQL 查询优化技术的基础上,主要结合传统SQL操作优化、深度分析 MySQL 源代码、现代数据库发展几方面进行诸如参数调优,MySQL关联查询,重写相关规则等容展开优化分析研究。 关键词:查询优化,查询重用,查询重写,计划优化

一、传统SQL查询优化操作 1.选取最适用的字段属性 MySQL可以很好的支持大数据量的存取,但是一般说来,数据库中的表越小,在它上面执行的查询也就会越快。因此,在创建表的时候,为了获得更好的性能,我们可以将表中字段的宽度设得尽可能小。例如,在定义邮政编码这个字段时,如果将其设置为CHAR(255),显然给数据库增加了不必要的空间,甚至使用VARCHAR这种类型也是多余的,因为CHAR(6)就可以很好的完成任务了。同样的,如果可以的话,我们应该使用MEDIUMINT而不是BIGIN来定义整型字段。 另外一个提高效率的方法是在可能的情况下,应该尽量把字段设置为NOT NULL,这样在将来执行查询的时候,数据库不用去比较NULL值。 对于某些文本字段,例如“省份”或者“性别”,我们可以将它们定义为ENUM类型。因为在MySQL中,ENUM类型被当作数值型数据来处理,而数值型数据被处理起来的速度要比文本类型快得多。这样,我们又可以提高数据库的性能。 2.使用连接(JOIN)来代替子查询(Sub-Queries) MySQL从4.1开始支持SQL的子查询。这个技术可以使用SELECT语句来创建一个单列的查询结果,然后把这个结果作为过滤条件用在另一个查询中。例如,我们要将客户基本信息表中没有任何订单的客户删除掉,就可以利用子查询先从销售信息表中将所有发出订单的客户ID取出来,然后将结果传递给主查询,如下所示: DELETE FROM customerinfo WHERE CustomerID NOT in (SELECT CustomerID FROM salesinfo ) 使用子查询可以一次性的完成很多逻辑上需要多个步骤才能完成的SQL操作,同时也可以避免事务或者表锁死,并且写起来也很容易。但是,有些情况下,

万字总结:学习MySQL优化原理,这一篇就够了!

万字总结:学习MySQL优化原理,这一篇就够了! Java开源分享 说起MySQL的查询优化,相信大家收藏了一堆奇技淫巧:不能使用SELECT *、不使用NULL字段、合理创建索引、为字段选择合适的数据类型..... 你是否真的理解这些优化技巧?是否理解其背后的工作原理?在实际场景下性能真有提升吗?我想未必。因而理解这些优化建议背后的原理就尤为重要,希望本文能让你重新审视这些优化建议,并在实际业务场景下合理的运用。 MySQL逻辑架构 如果能在头脑中构建一幅MySQL各组件之间如何协同工作的架构图,有助于深入理解MySQL服务器。下图展示了MySQL的逻辑架构图。 MySQL逻辑架构整体分为三层,最上层为客户端层,并非MySQL所独有,诸如:连接处理、授权认证、安全等功能均在这一层处理。 MySQL大多数核心服务均在中间这一层,包括查询解析、分析、优化、缓存、内置函数(比如:时间、数学、加密等函数)。所有的跨存储引擎的功能也在这一层实现:存储过程、触发器、视图等。最下层为存储引擎,其负责MySQL中的数据存储和提取。和Linux下的文件系统类似,每种存储引擎都有其优势和劣势。中间的服务层通过API与存储引擎通信,这些API接口屏蔽了不同存储引擎间的差异。 MySQL查询过程

我们总是希望MySQL能够获得更高的查询性能,最好的办法是弄清楚MySQL是如何优化和执行查询的。一旦理解了这一点,就会发现:很多的查询优化工作实际上就是遵循一些原则让MySQL的优化器能够按照预想的合理方式运行而已。 当向MySQL发送一个请求的时候,MySQL到底做了些什么呢? MySQL查询过程 客户端/服务端通信协议 MySQL客户端/服务端通信协议是“半双工”的:在任一时刻,要么是服务器向客户端发送数据,要么是客户端向服务器发送数据,这两个动作不能同时发生。一旦一端开始发送消息,另一端要接收完整个消息才能响应它,所以我们无法也无须将一个消息切成小块独立发送,也没有办法进行流量控制。 客户端用一个单独的数据包将查询请求发送给服务器,所以当查询语句很长的时候,需要设置max_allowed_packet参数。但是需要注意的是,如果查询实在是太大,服务端会拒绝接收更多数据并抛出异常。 与之相反的是,服务器响应给用户的数据通常会很多,由多个数据包组成。但是当服务器响应客户端请求时,客户端必须完整的接收整个返回结果,而不能简单的只取前面几条结果,然后让服务器停止发送。因而在实际开发中,尽量保持查询简单且只返回必需的数据,减小通信间数据包的大小和数量是一个非常好的习惯,这也是查询中尽量避免使用SELECT *以及加上LIMIT限制的原因之一。 查询缓存

mysql的性能检查和调优

一、识别有问题的查询语句 processlist命令的输出结果显示了有哪些线程在运行,可以帮助识别出有问题的查询语句,两种方式使用这个命令。 1. 进入m ysql/bin目录下输入mysqladmin processlist; 2. 启动m ysql,输入show processlist; 如果有SUPER 权限,则可以看到全部的线程,否则,只能看到自己发起的线程(这是指,当前对应的MySQL帐户运行的线程)。 得到数据形式如下(只截取了三条): mysql> show processlist; +-----+-------------+--------------------+-------+---------+-------+----------------------------------+---------- | Id | User | Host | db | Command | Tim e| State | Info +-----+-------------+--------------------+-------+---------+-------+----------------------------------+---------- |207|root |192.168.0.20:51718 |m ytest | Sleep | 5 | | NULL |208|root |192.168.0.20:51719 |m ytest | Sleep | 5 | | NULL |220|root |192.168.0.20:51731 |m ytest |Query | 84 | Locked | select bookname,culture,value,type from book where id=001 先简单说一下各列的含义和用途,第一列,id,不用说了吧,一个标识,你要kill一个语句的时候很有用。user列,显示单前用户,如果不是root,这个命令就只显示你权限范围内的sql 语句。host列,显示这个语句是从哪个ip的哪个端口上发出的。呵呵,可以用来追踪出问题语句的用户。db列,显示这个进程目前连接的是哪个数据库。command列,显示当前连接的执行的命令,一般就是休眠(sleep),查询(query),连接(connect)。tim e列,此这个状态持续的时间,单位是秒。state列,显示使用当前连接的sql语句的状态,很重要的列,后续会有所有的状态的描述,请注意,state只是语句执行中的某一个状态,一个sql语句,已查询为例,可能需要经过copying to t m p table,Sorting result,Sending data等状态才可以完成,info列,显示这个sql语句,因为长度有限,所以长的sql语句就显示不全,但是一个判断问题语句的重要依据。 这个命令中最关键的就是state列,m ysql列出的状态主要有以下几种: Checking table 正在检查数据表(这是自动的)。 Closing tables 正在将表中修改的数据刷新到磁盘中,同时正在关闭已经用完的表。这是一个很快的操作,如果不是这样的话,就应该确认磁盘空间是否已经满了或者磁盘是否正处于重负中。 Connect Out 复制从服务器正在连接主服务器。 Copying to tmp table on disk 由于临时结果集大于t m p_table_size,正在将临时表从内存存储转为磁盘存储以此节省内存。 Creating t m p table 正在创建临时表以存放部分查询结果。

MySQL数据库性能(SQL)优化方案

MySQL数据库性能(SQL)优化方案本文探讨了提高MySQL 数据库性能的思路,并从8个方面给出了具体的解决方法。 1、选取最适用的字段属性 MySQL可以很好的支持大数据量的存取,但是一般说来,数据库中的表越小,在它上面执行的查询也就会越快。因此,在创建表的时候,为了获得更好的性能,我们可以将表中字段的宽度设得尽可能小。例如,在定义邮政编码这个字段时,如果将其设置为CHAR(255),显然给数据库增加了不必要的空间,甚至使用VARCHAR这种类型也是多余的,因为CHAR(6)就可以很好的完成任务了。同样的,如果可以的话,我们应该使用MEDIUMINT而不是BIGIN 来定义整型字段。 另外一个提高效率的方法是在可能的情况下,应该尽量把字段设置为NOT NULL,这样在将来执行查询的时候,数据库不用去比较NULL值。 对于某些文本字段,例如“省份”或者“性别”,我们可以将它们定义为ENUM类型。因为在MySQL中,ENUM类型被当作数值型数据来处理,而数值型数据被处理起来的速度要比文本类型快得多。这样,我们又可以提高数据库的性能。 2、使用连接(JOIN)来代替子查询(Sub-Queries) MySQL从4.1开始支持SQL的子查询。这个技术可以使用SELECT语句来创建一个单列的查询结果,然后把这个结果作为过滤条件用在另一个查询中。例如,我们要将客户基本信息表中没有任何订单的客户删除掉,就可以利用子查询先从销售信息表中将所有发出订单的客户ID取出来,然后将结果传递给主查询,如下所示: DELETE FROM customerinfo WHERE CustomerID NOT in (SELECT CustomerID FROM salesinfo )

MySQL 数据库性能优化之表结构优化

很多人都将数据库设计范式作为数据库表结构设计“圣经”,认为只要按照这个范式需求设计,就能让设计出来的表结构足够优化,既能保证性能优异同时还能满足扩展性要求。殊不知,在N年前被奉为“圣经”的数据库设计3范式早就已经不完全适用了。这里我整理了一些比较常见的数据库表结构设计方面的优化技巧,希望对大家有用。 由于MySQL数据库是基于行(Row)存储的数据库,而数据库操作 IO 的时候是以 page(block)的方式,也就是说,如果我们每条记录所占用的空间量减小,就会使每个page中可存放的数据行数增大,那么每次 IO 可访问的行数也就增多了。反过来说,处理相同行数的数据,需要访问的 page 就会减少,也就是 IO 操作次数降低,直接提升性能。此外,由于我们的内存是有限的,增加每个page 中存放的数据行数,就等于增加每个内存块的缓存数据量,同时还会提升内存换中数据命中的几率,也就是缓存命中率。 数据类型选择 数据库操作中最为耗时的操作就是 IO 处理,大部分数据库操作 90% 以上的时间都花在了 IO 读写上面。所以尽可能减少 IO 读写量,可以在很大程度上提高数据库操作的性能。 我们无法改变数据库中需要存储的数据,但是我们可以在这些数据的存储方式方面花一些心思。下面的这些关于字段类型的优化建议主要适用于记录条数较多,数据量较大的场景,因为精细化的数据类型设置可能带来维护成本的提高,过度优化也可能会带来其他的问题: 1、数字类型:非万不得已不要使用DOUBLE,不仅仅只是存储长度的问题,同时还会存在精确性的问题。同样,固定精度的小数,也不建议使用DECIMAL,建议乘以固定倍数转换成整数存储,可以大大节省存储空间,且不会带来任何附加维护成本。对于整数的存储,在数据量较大的情况下,建议区分开 TINYINT / INT / BIGINT 的选择,因为三者所占用的存储空间也有很大的差别,能确定不会使用负数的字段,建议添加unsigned定义。当然,如果数据量较小的数据库,也可以不用严格区分三个整数类型。 2、字符类型:非万不得已不要使用 TEXT 数据类型,其处理方式决定了他的性能要低于char或者是varchar类型的处理。定长字段,建议使用 CHAR 类型,不定长字段尽量使用 VARCHAR,且仅仅设定适当的最大长度,而不是非常随意的给一个很大的最大长度限定,因为不同的长度范围,MySQL也会有不一样的存储处理。 3、时间类型:尽量使用TIMESTAMP类型,因为其存储空间只需要 DATETIME 类型的一半。对于只需要精确到某一天的数据类型,建议使用DATE类型,因为他的存储空间只需要3个字节,比TIMESTAMP还少。不建议通过INT类型类存储一个unix timestamp 的值,因为这太不直观,会给维护带来不必要的麻烦,同时还不会带来任何好处。

mysql性能优化培训

一概述 数据库属于IO 密集型的应用程序,其主要职责就是数据的管理及存储工作。 而我们知道,从内存中读取一个数据库的时间是微秒级别,而从一块普通硬盘上读 取一个IO是在毫秒级别,二者相差3个数量级。所以,要优化数据库,首先第一 步需要优化的就是IO,尽可能将磁盘IO转化为内存IO。 所以我们先从MySQL 数据库IO相关参数(缓存参数)的角度来看看可以通过哪些参数进行IO优化 二表结构优化: 由于MySQL数据库是基于行(Row)存储的数据库,而数据库操作IO 的时候是以page(block)的方式,也就是说,如果我们每条记录所占用的空间量减小, 就会使每个page中可存放的数据行数增大,那么每次IO 可访问的行数也就增多 了。反过来说,处理相同行数的数据,需要访问的page 就会减少,也就是IO 操 作次数降低,直接提升性能。此外,由于我们的内存是有限的,增加每个page中 存放的数据行数,就等于增加每个内存块的缓存数据量,同时还会提升内存换中数 据命中的几率,也就是缓存命中率。 优化原则:使数据量最小,性能的瓶颈在于磁盘性能,数据量越小,磁盘读取数据的速度就越快,同时,在较小的列上建立索引,索引文件占用的资源也会更少。 1.尽可能地使用最有效(最小)的数据类型。 MySQL有很多节省磁盘空间和内存的专业化类型。尽可能使用较小的整数类型使表更小。例如,MEDIUMINT经常比INT好一些,因为MEDIUMINT列使用的空间 要少25% 2.尽量使用NOT NULL NULL 类型比较特殊,SQL 难优化。虽然MySQL NULL类型和Oracle 的NULL 有差异,会进入索引中,但如果是一个组合索引,那么这个NULL 类型的字段会极 大影响整个索引的效率。此外,NULL 在索引中的处理也是特殊的,也会占用额外 的存放空间。很多人觉得NULL 会节省一些空间,所以尽量让NULL来达到节省IO 的目的,但是大部分时候这会适得其反,虽然空间上可能确实有一定节省,倒是带 来了很多其他的优化问题,不但没有将IO量省下来,反而加大了SQL的IO量。所 以尽量确保DEFAULT 值不是NULL,也是一个很好的表结构设计优化习惯。 3.只创建你确实需要的索引。 索引对检索有好处,但是当你需要快速存储东西时就变得糟糕。如果主要通过搜索列的组合来存取一个表,对它们做一个索引。第一个索引部分应该是最常用的 列。如果从表中选择时总是使用许多列,应该首先以更多的副本使用列以获得更好

相关主题
相关文档
最新文档