优化MySQL数据库性能的八大妙招

优化MySQL 数据库性能的八大妙招(1)本文探讨了提高MySQL数据库性能的思路，并从8个方面给出了具体的解决方法。这八个方面是：1、选取最适用的字段属性；2、使用连接(JOIN来代替子查询(Sub-Queries) 3、使用联合(UNION)来代替手动创建的临时表；4、事务；5、锁定表；6、使用外键；7、使用索引；8、优化的查询语句。

AD：

本文探讨了提高MySQL 数据库性能的思路，并从8 个方面给出了具体的解决方法。

1、选取最适用的字段属性

MySQL可以很好的支持大数据量的存取，但是一般说来，数据库中的表越小，

在它上面执行的查询也就会越快。因此，在创建表的时候，为了获得更好的性能，我们可以将表中字段的宽度设得尽可能小。例如，在定义邮政编码这个字段时，如果将其设置为CHAR(255)显然给数据库增加了不必要的空间，甚至使用VARCHAF这种类型也是多余的，因为CHAR(6就可以很好的完成任务了。同样的，如果可以的话，我们应该使用MEDIUMINT而不是BIGIN来定义整型字段。

另外一个提高效率的方法是在可能的情况下，应该尽量把字段设置为NOT NULL，这样在将来执行查询的时候，数据库不用去比较NULL值。

对于某些文本字段，例如省份”或者性别”我们可以将它们定义为ENUM类型。因为在MySQL中，ENUM类型被当作数值型数据来处理，而数值型数据被处理起来的速度要比文本类型快得多。这样，我们又可以提高数据库的性能。

2、使用连接(JOIN来代替子查询(Sub-Queries)

MySQL从开始支持SQL的子查询。这个技术可以使用SELECT S句来创建一个单列

的查询结果，然后把这个结果作为过滤条件用在另一个查询中。例如，我们

要将客户基本信息表中没有任何订单的客户删除掉，就可以利用子查询先从销售

信息表中将所有发出订单的客户ID取出来，然后将结果传递给主查询，如下所示：

DELETE FROM customeri nfo

WHERE CustomerID NOT in (SELECT CustomerID FROM sales info )

使用子查询可以一次性的完成很多逻辑上需要多个步骤才能完成的SQL操作，同

时也可以避免事务或者表锁死，并且写起来也很容易。但是，有些情况下，子

查询可以被更有效率的连接JOIN)..替代。例如，假设我们要将所有没有订单记录的用户取出来，可以用下面这个查询完成：

SELECT * FROM customeri nfo

WHERE CustomerID NOT in (SELECT CustomerID FROM sales info )

如果使用连接(JOIN)..来完成这个查询工作，速度将会快很多。尤其是当sales info 表中对CustomerID建有索引的话，性能将会更好，查询如下：

SELECT * FROM customeri nfo

LEFT JOIN salesi nfoON =salesi nfo.

CustomerID

WHERE IS NULL

连接(JOIN)..之所以更有效率一些，是因为MySQL不需要在内存中创建临时表来完成这个逻辑上的需要两个步骤的查询工作。

3、使用联合(UNION)来代替手动创建的临时表

MySQL从的版本开始支持UNION查询，它可以把需要使用临时表的两条或更多的SELECT查询合并的一个查询中。在客户端的查询会话结束的时候，临时表会被自动删除，从而保证数据库整齐、高效。使用UNION来创建查询的时候，我们只需要用UNION作为关键字把多个SELECT语句连接起来就可以了，要注意的是所有SELECT 语句中的字段数目要想同。下面的例子就演示了一个使用UNION的查询。

SELECT Name, Pho ne FROM clie nt

UNION

SELECT Name, BirthDate FROM author

UNION

SELECT Name, Supplier FROM product

4、事务

尽管我们可以使用子查询(Sub-Queries)连接(JOIN和联合(UNION)来创建各种各样的查询，但不是所有的数据库操作都可以只用一条或少数几条SQL语句就可

以完成的。更多的时候是需要用到一系列的语句来完成某种工作。但是在这种情

况下，当这个语句块中的某一条语句运行出错的时候，整个语句块的操作就会

变得不确定起来。设想一下，要把某个数据同时插入两个相关联的表中，可能会

出现这样的情况：第一个表中成功更新后，数据库突然出现意外状况，造成第

二个表中的操作没有完成，这样，就会造成数据的不完整，甚至会破坏数据库中的数据。要避免这种情况，就应该使用事务，它的作用是：要么语句块中每条

语句都操作成功，要么都失败。换句话说，就是可以保持数据库中数据的一致性和完整性。事物以BEGIN关键字开始，COMMIT关键字结束。在这之间的一条SQL操作失败，那么，ROLLBACKS令就可以把数据库恢复到BEGIN开始之前的状态。

BEGIN;

INSERT INTO salesi nfo SET CustomerlD=14;

UPDATE inven tory SET Qua ntity=11

WHERE item='book';

COMMIT;

事务的另一个重要作用是当多个用户同时使用相同的数据源时，它可以利用锁定数据库的方法来为用户提供一种安全的访问方式，这样可以保证用户的操作不被其它的用户所干扰。

5、锁定表

尽管事务是维护数据库完整性的一个非常好的方法，但却因为它的独占性，有时

会影响数据库的性能，尤其是在很大的应用系统中。由于在事务执行的过程中, 数据库将会被锁定，因此其它的用户请求只能暂时等待直到该事务结束。如果一个数据库系统只有少数几个用户来使用，事务造成的影响不会成为一个太大的问题;但假设有成千上万的用户同时访问一个数据库系统，例如访问一个电子商务网站，就会产生比较严重的响应延迟。

其实，有些情况下我们可以通过锁定表的方法来获得更好的性能。下面的例子就

用锁定表的方法来完成前面一个例子中事务的功能。

LOCK TABLE in ve ntory WRITE

SELECT Qua ntity FROM inven tory

WHEREItem='book';

UPDATE inven tory SET Qua ntity=11

WHEREItem='book';

UNLOCK TABLES

这里，我们用一个SELECT语句取出初始数据，通过一些计算，用UPDATE语

句将新值更新到表中。包含有WRITE关键字的LOCK TABLES句可以保证在UNLOCK TABLE命令被执行之前，不会有其它的访问来对inventory进行插入、

更新或者删除的操作。

6使用外键

锁定表的方法可以维护数据的完整性，但是它却不能保证数据的关联性。这个时候我们就可以使用外键。例如，外键可以保证每一条销售记录都指向某一个存在

的客户。在这里，外键可以把customerinfo表中的CustomerID映射到salesinfo 表中CustomerID，任何一条没有合法CustomerID的记录都不会被更新或插入到sales info 中。

CREATE TABLE customeri nfo

(

CustomerlD INT NOT NULL ,

PRIMARY KEY ( CustomerID )

)TYPE = INNODB;

CREATE TABLE sales info

(

SalesID INT NOT NULL,

CustomerID INT NOT NULL,

PRIMARY KEY(CustomerlD, SalesID),

FOREIGN KEY (CustomerID) REFERENCES customeri nfo

(CustomerID) ON DELETECASCADE

)TYPE = INNODB;

注意例子中的参数“ON DELETE CASCA”该参数保证当customerinfo表中的一

条客户记录被删除的时候，salesinfo表中所有与该客户相关的记录也会被自动删除。如果要在MySQL中使用外键，一定要记住在创建表的时候将表的类型定义为事务安全表Inn oDB类型。该类型不是MySQL表的默认类型。定义的方法是在CREATE TABL语句中加上TYPE=INNOD B如例中所示7、使用索引

索引是提高数据库性能的常用方法，它可以令数据库服务器以比没有索引快得多的速度检索特定的行，尤其是在查询语句当中包含有MAX(), MIN()和ORDERBY

这些命令的时候，性能提高更为明显。那该对哪些字段建立索引呢一般说来，索引应建立在那些将用于JOIN, WHER判断和ORDER BYI*序的字段上。尽量不要对数据库中某个含有大量重复的值的字段建立索引。对于一个ENUM 类型的字段来说，出现大量重复值是很有可能的情况，例如customerinfo中的“provinee ” 字段，在这样的字段上建立索引将不会有什么帮助;相反，还有可能降低数据库的性能。我们在创建表的时候可以同时创建合适的索引，也可以使用ALTER TABLE 或CREATE INDE在以后创建索引。此外，MySQL

从版本 3.23.23开始支持全文索引和搜索。全文索引在MySQL 中是一个FULLTEXT 类型索引，但仅能用于MyISAM 类型的表。对于一个大的数据库，将数据装载到一个

没有FULLTEX索引的表中，然后再使用ALTER TABL或CREATE INDE创建索引，将是非常快的。但如果将数据装载到一个已经有FULLTEX索引的表中，执行过程将会非常慢。

8、优化的查询语句

绝大多数情况下，使用索引可以提高查询的速度，但如果SQL语句使用不恰当的话，索引将无法发挥它应有的作用。下面是应该注意的几个方面。首先，最好是在相同类型的字段间进行比较的操作。在MySQL 版之前，这甚至是一个必须的条件。例如不能将一个建有索引的INT字段和BIGINT字段进行比较但是作为特殊的情况，在CHAR类型的字段和VARCHAF类型字段的字段大小相同的时候，可以将它们进行比较。其次，在建有索引的字段上尽量不要使用函数进行操作。

例如，在一个DATE类型的字段上使用YEAE(函数时，将会使索引不能发挥应有的作用。所以，下面的两个查询虽然返回的结果一样，但后者要比前者快得多。

SELECT * FROM order WHERE YEAR(OrderDate)<2001;

SELECT * FROM order WHERE OrderDate<"2001-01-01";

同样的情形也会发生在对数值型字段进行计算的时候：

SELECT * FROM in ve ntory WHERE Amou nt/7<24;

SELECT * FROM inven tory WHERE Amou nt<24*7;

上面的两个查询也是返回相同的结果，但后面的查询将比前面的一个快很多。第三，在搜索字符型字段时，我们有时会使用LIKE关键字和通配符，这种做法虽

然简单，但却也是以牺牲系统性能为代价的。例如下面的查询将会比较表中的每一条记录。

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.wendangku.net/doc/d78405911.html,f配置说明详解 （16G内存） MYSQL服务器https://www.wendangku.net/doc/d78405911.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.只创建你确实需要的索引。 索引对检索有好处，但是当你需要快速存储东西时就变得糟糕。如果主要通过搜索列的组合来存取一个表，对它们做一个索引。第一个索引部分应该是最常用的 列。如果从表中选择时总是使用许多列，应该首先以更多的副本使用列以获得更好