mysql数据库优化（转）

   今天，数据库的操做愈来愈成为整个应用的性能瓶颈了，这点对于Web应用尤为明显。关于数据库的性能，这并不仅是DBA才须要担忧的事，而这更是咱们程序员须要去关注的事情。当咱们去设计数据库表结构，对操做数据库时(尤为是查表时的SQL语句)，咱们都须要注意数据操做的性能。这里，咱们不会讲过多的SQL语句的优化，而只是针对MySQL这一Web应用最多的数据库。但愿下面的这些优化技巧对你有用。

1. 为查询缓存优化你的查询

大多数的MySQL服务器都开启了查询缓存。这是提升性最有效的方法之一，并且这是被MySQL的数据库引擎处理的。当有不少相同的查询被执行了屡次的时候，这些查询结果会被放到一个缓存中，这样，后续的相同的查询就不用操做表而直接访问缓存结果了。

这里最主要的问题是，对于程序员来讲，这个事情是很容易被忽略的。由于，咱们某些查询语句会让MySQL不使用缓存。请看下面的示例：

上面两条SQL语句的差异就是 CURDATE() ，MySQL的查询缓存对这个函数不起做用。因此，像 NOW() 和 RAND()

或是其它的诸如此类的SQL函数都不会开启查询缓存，由于这些函数的返回是会不定的易变的。因此，你所须要的就是用一个变量来代替MySQL的函数，从而开启缓存。

2. EXPLAIN 你的 SELECT 查询

使用 EXPLAIN 关键字可让你知道MySQL是如何处理你的SQL语句的。这能够帮你分析你的查询语句或是表结构的性能瓶颈。

EXPLAIN 的查询结果还会告诉你你的索引主键被如何利用的，你的数据表是如何被搜索和排序的……等等，等等。

挑一个你的SELECT语句(推荐挑选那个最复杂的，有多表联接的)，把关键字EXPLAIN加到前面。你可使用phpmyadmin来作这个事。而后，你会看到一张表格。下面的这个示例中，咱们忘记加上了group_id索引，而且有表联接：

 

当咱们为 group_id 字段加上索引后：

 

咱们能够看到，前一个结果显示搜索了 7883 行，然后一个只是搜索了两个表的 9 和 16 行。查看rows列可让咱们找到潜在的性能问题。

3. 当只要一行数据时使用 LIMIT 1

当你查询表的有些时候，你已经知道结果只会有一条结果，但由于你可能须要去fetch游标，或是你也许会去检查返回的记录数。

在这种状况下，加上 LIMIT 1 能够增长性能。这样同样，MySQL数据库引擎会在找到一条数据后中止搜索，而不是继续日后查少下一条符合记录的数据。

下面的示例，只是为了找一下是否有“中国”的用户，很明显，后面的会比前面的更有效率。(请注意，第一条中是Select *，第二条是Select 1)

 

4. 为搜索字段建索引

索引并不必定就是给主键或是惟一的字段。若是在你的表中，有某个字段你总要会常常用来作搜索，那么，请为其创建索引吧。

 

从上图你能够看到那个搜索字串 “last_name LIKE ‘a%’”，一个是建了索引，一个是没有索引，性能差了4倍左右。

另外，你应该也须要知道什么样的搜索是不能使用正常的索引的。例如，当你须要在一篇大的文章中搜索一个词时，如： “WHERE

post_content LIKE ‘%apple%’”，索引多是没有意义的。你可能须要使用MySQL全文索引

或是本身作一个索引(好比说：搜索关键词或是Tag什么的)

5. 在Join表的时候使用至关类型的例，并将其索引

若是你的应用程序有不少 JOIN 查询，你应该确认两个表中Join的字段是被建过索引的。这样，MySQL内部会启动为你优化Join的SQL语句的机制。

并且，这些被用来Join的字段，应该是相同的类型的。例如：若是你要把 DECIMAL 字段和一个 INT 字段Join在一块儿，MySQL就没法使用它们的索引。对于那些STRING类型，还须要有相同的字符集才行。(两个表的字符集有可能不同)

 

6. 千万不要 ORDER BY RAND()

想打乱返回的数据行?随机挑一个数据?真不知道谁发明了这种用法，但不少新手很喜欢这样用。但你确不了解这样作有多么可怕的性能问题。

若是你真的想把返回的数据行打乱了，你有N种方法能够达到这个目的。这样使用只让你的数据库的性能呈指数级的降低。这里的问题是：MySQL会不得不去执行RAND()函数(很耗CPU时间)，并且这是为了每一行记录去记行，而后再对其排序。就算是你用了Limit1也无济于事(由于要排序)

下面的示例是随机挑一条记录

 

7. 避免 SELECT *

从数据库里读出越多的数据，那么查询就会变得越慢。而且，若是你的数据库服务器和WEB服务器是两台独立的服务器的话，这还会增长网络传输的负载。

因此，你应该养成一个须要什么就取什么的好的习惯。

 

8. 永远为每张表设置一个ID

咱们应该为数据库里的每张表都设置一个ID作为其主键，并且最好的是一个INT型的(推荐使用UNSIGNED)，并设置上自动增长的AUTO_INCREMENT标志。

就算是你 users 表有一个主键叫 “email”的字段，你也别让它成为主键。使用 VARCHAR 类型来当主键会使用得性能降低。另外，在你的程序中，你应该使用表的ID来构造你的数据结构。

并且，在MySQL数据引擎下，还有一些操做须要使用主键，在这些状况下，主键的性能和设置变得很是重要，好比，集群，分区……

在这里，只有一个状况是例外，那就是“关联表”的“外键”，也就是说，这个表的主键，经过若干个别的表的主键构成。咱们把这个状况叫作“外键”。好比：有一个“学生表”有学生的ID，有一个“课程表”有课程ID，那么，“成绩表”就是“关联表”了，其关联了学生表和课程表，在成绩表中，学生ID和课程ID叫“外键”其共同组成主键。

9. 使用 ENUM 而不是 VARCHAR

ENUM 类型是很是快和紧凑的。在实际上，其保存的是 TINYINT，但其外表上显示为字符串。这样一来，用这个字段来作一些选项列表变得至关的完美。

若是你有一个字段，好比“性别”，“国家”，“民族”，“状态”或“部门”，你知道这些字段的取值是有限并且固定的，那么，你应该使用 ENUM 而不是 VARCHAR。

MySQL也有一个“建议”(见第十条)告诉你怎么去从新组织你的表结构。当你有一个 VARCHAR 字段时，这个建议会告诉你把其改为 ENUM 类型。使用 PROCEDURE ANALYSE() 你能够获得相关的建议。

10. 从 PROCEDURE ANALYSE() 取得建议

PROCEDURE ANALYSE() 会让 MySQL 帮你去分析你的字段和其实际的数据，并会给你一些有用的建议。只有表中有实际的数据，这些建议才会变得有用，由于要作一些大的决定是须要有数据做为基础的。

例如，若是你建立了一个 INT 字段做为你的主键，然而并无太多的数据，那么，PROCEDURE

ANALYSE()会建议你把这个字段的类型改为 MEDIUMINT 。或是你使用了一个 VARCHAR

字段，由于数据很少，你可能会获得一个让你把它改为 ENUM 的建议。这些建议，都是可能由于数据不够多，因此决策作得就不够准。

在phpmyadmin里，你能够在查看表时，点击 “Propose table structure” 来查看这些建议

 

必定要注意，这些只是建议，只有当你的表里的数据愈来愈多时，这些建议才会变得准确。必定要记住，你才是最终作决定的人。

11. 尽量的使用 NOT NULL

除非你有一个很特别的缘由去使用 NULL 值，你应该老是让你的字段保持 NOT NULL。这看起来好像有点争议，请往下看。

首先，问问你本身“Empty”和“NULL”有多大的区别(若是是INT，那就是0和NULL)?若是你以为它们之间没有什么区别，那么你就不要使用NULL。(你知道吗?在 Oracle 里，NULL 和 Empty 的字符串是同样的!)

不要觉得 NULL 不须要空间，其须要额外的空间，而且，在你进行比较的时候，你的程序会更复杂。 固然，这里并非说你就不能使用NULL了，现实状况是很复杂的，依然会有些状况下，你须要使用NULL值。

12. Prepared Statements

Prepared Statements很像存储过程，是一种运行在后台的SQL语句集合，咱们能够从使用 prepared statements 得到不少好处，不管是性能问题仍是安全问题。

Prepared Statements

能够检查一些你绑定好的变量，这样能够保护你的程序不会受到“SQL注入式”攻击。固然，你也能够手动地检查你的这些变量，然而，手动的检查容易出问题，并且很常常会被程序员忘了。当咱们使用一些framework或是ORM的时候，这样的问题会好一些。

在性能方面，当一个相同的查询被使用屡次的时候，这会为你带来可观的性能优点。你能够给这些Prepared Statements定义一些参数，而MySQL只会解析一次。

虽然最新版本的MySQL在传输Prepared Statements是使用二进制形势，因此这会使得网络传输很是有效率。

固然，也有一些状况下，咱们须要避免使用Prepared Statements，由于其不支持查询缓存。但听说版本5.1后支持了。

在PHP中要使用prepared statements，你能够查看其使用手册：mysqli 扩展 或是使用数据库抽象层，如： PDO.

 

13. 无缓冲的查询

正常的状况下，当你在当你在你的脚本中执行一个SQL语句的时候，你的程序会停在那里直到没这个SQL语句返回，而后你的程序再往下继续执行。你可使用无缓冲查询来改变这个行为。

mysql_unbuffered_query()

发送一个SQL语句到MySQL而并不像mysql_query()同样去自动fethch和缓存结果。这会至关节约不少可观的内存，尤为是那些会产生大量结果的查询语句，而且，你不须要等到全部的结果都返回，只须要第一行数据返回的时候，你就能够开始立刻开始工做于查询结果了。

然而，这会有一些限制。由于你要么把全部行都读走，或是你要在进行下一次的查询前调用 mysql_free_result()

清除结果。并且， mysql_num_rows() 或 mysql_data_seek()

将没法使用。因此，是否使用无缓冲的查询你须要仔细考虑。

14. 把IP地址存成 UNSIGNED INT

不少程序员都会建立一个 VARCHAR(15)

字段来存放字符串形式的IP而不是整形的IP。若是你用整形来存放，只须要4个字节，而且你能够有定长的字段。并且，这会为你带来查询上的优点，尤为是当你须要使用这样的WHERE条件：IP

between ip1 and ip2。

咱们必须要使用UNSIGNED INT，由于 IP地址会使用整个32位的无符号整形。

而你的查询，你可使用 INET_ATON() 来把一个字符串IP转成一个整形，并使用 INET_NTOA() 把一个整形转成一个字符串IP。在PHP中，也有这样的函数 ip2long() 和 long2ip()。

 

15. 固定长度的表会更快

若是表中的全部字段都是“固定长度”的，整个表会被认为是 “static” 或 “fixed-length”。

例如，表中没有以下类型的字段：

VARCHAR，TEXT，BLOB。只要你包括了其中一个这些字段，那么这个表就不是“固定长度静态表”了，这样，MySQL

引擎会用另外一种方法来处理。

固定长度的表会提升性能，由于MySQL搜寻得会更快一些，由于这些固定的长度是很容易计算下一个数据的偏移量的，因此读取的天然也会很快。而若是字段不是定长的，那么，每一次要找下一条的话，须要程序找到主键。

而且，固定长度的表也更容易被缓存和重建。不过，惟一的反作用是，固定长度的字段会浪费一些空间，由于定长的字段不管你用不用，他都是要分配那么多的空间。

使用“垂直分割”技术(见下一条)，你能够分割你的表成为两个一个是定长的，一个则是不定长的。

16. 垂直分割

“垂直分割”是一种把数据库中的表按列变成几张表的方法，这样能够下降表的复杂度和字段的数目，从而达到优化的目的。(之前，在银行作过项目，见过一张表有100多个字段，很恐怖)

示例一：在Users表中有一个字段是家庭地址，这个字段是可选字段，相比起，并且你在数据库操做的时候除了我的信息外，你并不须要常常读取或是改写这个字段。那么，为何不把他放到另一张表中呢?

这样会让你的表有更好的性能，你们想一想是否是，大量的时候，我对于用户表来讲，只有用户ID，用户名，口令，用户角色等会被常用。小一点的表老是会有好的性能。

示例二： 你有一个叫 “last_login”

的字段，它会在每次用户登陆时被更新。可是，每次更新时会致使该表的查询缓存被清空。因此，你能够把这个字段放到另外一个表中，这样就不会影响你对用户ID，用户名，用户角色的不停地读取了，由于查询缓存会帮你增长不少性能。

另外，你须要注意的是，这些被分出去的字段所造成的表，你不会常常性地去Join他们，否则的话，这样的性能会比不分割时还要差，并且，会是极数级的降低。

17. 拆分大的 DELETE 或 INSERT 语句

若是你须要在一个在线的网站上去执行一个大的 DELETE 或 INSERT 查询，你须要很是当心，要避免你的操做让你的整个网站中止相应。由于这两个操做是会锁表的，表一锁住了，别的操做都进不来了。

Apache 会有不少的子进程或线程。因此，其工做起来至关有效率，而咱们的服务器也不但愿有太多的子进程，线程和数据库连接，这是极大的占服务器资源的事情，尤为是内存。

若是你把你的表锁上一段时间，好比30秒钟，那么对于一个有很高访问量的站点来讲，这30秒所积累的访问进程/线程，数据库连接，打开的文件数，可能不只仅会让你泊WEB服务Crash，还可能会让你的整台服务器立刻掛了。

因此，若是你有一个大的处理，你定你必定把其拆分，使用 LIMIT 条件是一个好的方法。下面是一个示例：

 

18. 越小的列会越快

对于大多数的数据库引擎来讲，硬盘操做多是最重大的瓶颈。因此，把你的数据变得紧凑会对这种状况很是有帮助，由于这减小了对硬盘的访问。

参看 MySQL 的文档 Storage Requirements 查看全部的数据类型。

若是一个表只会有几列罢了(好比说字典表，配置表)，那么，咱们就没有理由使用 INT 来作主键，使用 MEDIUMINT, SMALLINT 或是更小的 TINYINT 会更经济一些。若是你不须要记录时间，使用 DATE 要比 DATETIME 好得多。

固然，你也须要留够足够的扩展空间，否则，你往后来干这个事，你会死的很难看，参看Slashdot的例子(2009年11月06日)，一个简单的ALTER TABLE语句花了3个多小时，由于里面有一千六百万条数据。

19. 选择正确的存储引擎

在 MySQL 中有两个存储引擎 MyISAM 和 InnoDB，每一个引擎都有利有弊。酷壳之前文章《MySQL: InnoDB 仍是 MyISAM?》讨论和这个事情。

MyISAM

适合于一些须要大量查询的应用，但其对于有大量写操做并非很好。甚至你只是须要update一个字段，整个表都会被锁起来，而别的进程，就算是读进程都没法操做直到读操做完成。另外，MyISAM

对于 SELECT COUNT(*) 这类的计算是超快无比的。

InnoDB 的趋势会是一个很是复杂的存储引擎，对于一些小的应用，它会比 MyISAM 还慢。他是它支持“行锁” ，因而在写操做比较多的时候，会更优秀。而且，他还支持更多的高级应用，好比：事务。

下面是MySQL的手册

target=”_blank”MyISAM Storage Engine

InnoDB Storage Engine

20. 使用一个对象关系映射器(Object Relational Mapper)

使用 ORM (Object Relational Mapper)，你可以得到可靠的性能增涨。一个ORM能够作的全部事情，也能被手动的编写出来。可是，这须要一个高级专家。

ORM 的最重要的是“Lazy Loading”，也就是说，只有在须要的去取值的时候才会去真正的去作。但你也须要当心这种机制的反作用，由于这颇有可能会由于要去建立不少不少小的查询反而会下降性能。

ORM 还能够把你的SQL语句打包成一个事务，这会比单独执行他们快得多得多。

目前，我的最喜欢的PHP的ORM是：Doctrine。

21. 当心“永久连接”

“永久连接”的目的是用来减小从新建立MySQL连接的次数。当一个连接被建立了，它会永远处在链接的状态，就算是数据库操做已经结束了。并且，自从咱们的Apache开始重用它的子进程后——也就是说，下一次的HTTP请求会重用Apache的子进程，并重用相同的

MySQL 连接。

PHP手册：mysql_pconnect()

在理论上来讲，这听起来很是的不错。可是从我的经验(也是大多数人的)上来讲，这个功能制造出来的麻烦事更多。由于，你只有有限的连接数，内存问题，文件句柄数，等等。

并且，Apache 运行在极端并行的环境中，会建立不少不少的了进程。这就是为何这种“永久连接”的机制工做地很差的缘由。在你决定要使用“永久连接”以前，你须要好好地考虑一下你的整个系统的架构。

TechTarget中国原创内容，原文连接：http://www.searchdatabase.com.cn/showcontent_38045.htm

做者：学_无_止_境
连接：https://www.jianshu.com/p/9d438bbd2afc
來源：简书
简书著做权归做者全部，任何形式的转载都请联系做者得到受权并注明出处。

基本配置
你须要常常察看如下3个配置项。否则，可能很快就会出问题。

innodb_buffer_pool_size:这是你安装完InnoDB后第一个应该设置的选项。缓冲池是数据和索引缓存的地方：这个值越大越好，这能保证你在大多数的读取操做时使用的是内存而不是硬盘。典型的值是5-6GB(8GB内存)，20-25GB(32GB内存)，100-120GB(128GB内存)。

innodb_log_file_size：这是redo日志的大小。redo日志被用于确保写操做快速而可靠而且在崩溃时恢复。一直到MySQL 5.1，它都难于调整，由于一方面你想让它更大来提升性能，另外一方面你想让它更小来使得崩溃后更快恢复。幸运的是从MySQL 5.5以后，崩溃恢复的性能的到了很大提高，这样你就能够同时拥有较高的写入性能和崩溃恢复性能了。一直到MySQL 5.5，redo日志的总尺寸被限定在4GB(默承认以有2个log文件)。这在MySQL 5.6里被提升。

一开始就把innodb_log_file_size设置成512M(这样有1GB的redo日志)会使你有充裕的写操做空间。若是你知道你的应用程序须要频繁的写入数据而且你使用的时MySQL 5.6，你能够一开始就把它这是成4G。

max_connections:若是你常常看到‘Too many connections'错误，是由于max_connections的值过低了。这很是常见由于应用程序没有正确的关闭数据库链接，你须要比默认的151链接数更大的值。max_connection值被设高了(例如1000或更高)以后一个主要缺陷是当服务器运行1000个或更高的活动事务时会变的没有响应。在应用程序里使用链接池或者在MySQL里使用进程池有助于解决这一问题。
InnoDB配置
从MySQL 5.5版本开始，InnoDB就是默认的存储引擎而且它比任何其余存储引擎的使用都要多得多。那也是为何它须要当心配置的缘由。

innodb_file_per_table：这项设置告知InnoDB是否须要将全部表的数据和索引存放在共享表空间里（innodb_file_per_table = OFF） 或者为每张表的数据单独放在一个.ibd文件（innodb_file_per_table = ON）。每张表一个文件容许你在drop、truncate或者rebuild表时回收磁盘空间。这对于一些高级特性也是有必要的，好比数据压缩。可是它不会带来任何性能收益。你不想让每张表一个文件的主要场景是：有很是多的表（好比10k+）。

MySQL 5.6中，这个属性默认值是ON，所以大部分状况下你什么都不须要作。对于以前的版本你必需在加载数据以前将这个属性设置为ON，由于它只对新建立的表有影响。

innodb_flush_log_at_trx_commit：默认值为1，表示InnoDB彻底支持ACID特性。当你的主要关注点是数据安全的时候这个值是最合适的，好比在一个主节点上。可是对于磁盘（读写）速度较慢的系统，它会带来很巨大的开销，由于每次将改变flush到redo日志都须要额外的fsyncs。将它的值设置为2会致使不太可靠（reliable）由于提交的事务仅仅每秒才flush一次到redo日志，但对于一些场景是能够接受的，好比对于主节点的备份节点这个值是能够接受的。若是值为0速度就更快了，但在系统崩溃时可能丢失一些数据：只适用于备份节点。

innodb_flush_method: 这项配置决定了数据和日志写入硬盘的方式。通常来讲，若是你有硬件RAID控制器，而且其独立缓存采用write-back机制，并有着电池断电保护，那么应该设置配置为O_DIRECT；不然，大多数状况下应将其设为fdatasync（默认值）。sysbench是一个能够帮助你决定这个选项的好工具。

innodb_log_buffer_size: 这项配置决定了为还没有执行的事务分配的缓存。其默认值（1MB）通常来讲已经够用了，可是若是你的事务中包含有二进制大对象或者大文本字段的话，这点缓存很快就会被填满并触发额外的I/O操做。看看Innodb_log_waits状态变量，若是它不是0，增长innodb_log_buffer_size。
其余设置
query_cache_size: query cache（查询缓存）是一个众所周知的瓶颈，甚至在并发并很少的时候也是如此。 最佳选项是将其从一开始就停用，设置query_cache_size = 0（如今MySQL 5.6的默认值）并利用其余方法加速查询：优化索引、增长拷贝分散负载或者启用额外的缓存（好比memcache或redis）。若是你已经为你的应用启用了query cache而且尚未发现任何问题，query cache可能对你有用。这是若是你想停用它，那就得当心了。

log_bin：若是你想让数据库服务器充当主节点的备份节点，那么开启二进制日志是必须的。若是这么作了以后，还别忘了设置server_id为一个惟一的值。就算只有一个服务器，若是你想作基于时间点的数据恢复，这（开启二进制日志）也是颇有用的：从你最近的备份中恢复（全量备份），并应用二进制日志中的修改（增量备份）。二进制日志一旦建立就将永久保存。因此若是你不想让磁盘空间耗尽，你能够用 PURGE BINARY LOGS 来清除旧文件，或者设置 expire_logs_days 来指定过多少天日志将被自动清除。

记录二进制日志不是没有开销的，因此若是你在一个非主节点的复制节点上不须要它的话，那么建议关闭这个选项。

skip_name_resolve：当客户端链接数据库服务器时，服务器会进行主机名解析，而且当DNS很慢时，创建链接也会很慢。所以建议在启动服务器时关闭skip_name_resolve选项而不进行DNS查找。惟一的局限是以后GRANT语句中只能使用IP地址了，所以在添加这项设置到一个已有系统中必须格外当心。

 

Ref:

http://www.jb51.net/article/47419.htm

 

基本原则

1.尽可能少 join

　　MySQL 的优点在于简单，但这在某些方面其实也是其劣势。MySQL 优化器效率高，可是因为其统计信息的量有限，优化器工做过程出现误差的可能性也就更多。对于复杂的多表 Join，一方面因为其优化器受限，再者在 Join 这方面所下的功夫还不够，因此性能表现离 Oracle 等关系型数据库前辈仍是有必定距离。但若是是简单的单表查询，这一差距就会极小甚至在有些场景下要优于这些数据库前辈。

 

2.尽可能少排序

　　排序操做会消耗较多的 CPU 资源，因此减小排序能够在缓存命中率高等 IO 能力足够的场景下会较大影响 SQL 的响应时间。

　　对于MySQL来讲，减小排序有多种办法，好比：

　　上面误区中提到的经过利用索引来排序的方式进行优化

　　减小参与排序的记录条数

　　非必要不对数据进行排序

　　…

 

3.尽可能避免 select *

　　不少人看到这一点后以为比较难理解，上面不是在误区中刚刚说 select 子句中字段的多少并不会影响到读取的数据吗?

　　是的，大多数时候并不会影响到 IO 量，可是当咱们还存在 order by 操做的时候，select 子句中的字段多少会在很大程度上影响到咱们的排序效率，这一点能够经过我以前一篇介绍 MySQL ORDER BY 的实现分析的文章中有较为详细的介绍。

　　此外，上面误区中不是也说了，只是大多数时候是不会影响到 IO 量，当咱们的查询结果仅仅只须要在索引中就能找到的时候，仍是会极大减小 IO 量的。

 

4.尽可能用 join 代替子查询

　　虽然 Join 性能并不佳，可是和 MySQL 的子查询比起来仍是有很是大的性能优点。MySQL 的子查询执行计划一直存在较大的问题，虽然这个问题已经存在多年，可是到目前已经发布的全部稳定版本中都广泛存在，一直没有太大改善。虽然官方也在很早就认可这一问题，而且承诺尽快解决，可是至少到目前为止咱们尚未看到哪个版本较好的解决了这一问题。

 

5.尽可能少 or

　　当 where 子句中存在多个条件以“或”并存的时候，MySQL 的优化器并无很好的解决其执行计划优化问题，再加上 MySQL 特有的 SQL 与 Storage 分层架构方式，形成了其性能比较低下，不少时候使用 union all 或者是union(必要的时候)的方式来代替“or”会获得更好的效果。

 

6.尽可能用 union all 代替 union

　　union 和 union all 的差别主要是前者须要将两个(或者多个)结果集合并后再进行惟一性过滤操做，这就会涉及到排序，增长大量的 CPU 运算，加大资源消耗及延迟。因此当咱们能够确认不可能出现重复结果集或者不在意重复结果集的时候，尽可能使用 union all 而不是 union。

 

7.尽可能早过滤

　　这一优化策略其实最多见于索引的优化设计中(将过滤性更好的字段放得更靠前)。

　　在 SQL 编写中一样可使用这一原则来优化一些 Join 的 SQL。好比咱们在多个表进行分页数据查询的时候，咱们最好是可以在一个表上先过滤好数据分好页，而后再用分好页的结果集与另外的表 Join，这样能够尽量多的减小没必要要的 IO 操做，大大节省 IO 操做所消耗的时间。

 

8.避免类型转换

　　这里所说的“类型转换”是指 where 子句中出现 column 字段的类型和传入的参数类型不一致的时候发生的类型转换：

　　人为在column_name 上经过转换函数进行转换

　　直接致使 MySQL(实际上其余数据库也会有一样的问题)没法使用索引，若是非要转换，应该在传入的参数上进行转换

　　由数据库本身进行转换

　　若是咱们传入的数据类型和字段类型不一致，同时咱们又没有作任何类型转换处理，MySQL 可能会本身对咱们的数据进行类型转换操做，也可能不进行处理而交由存储引擎去处理，这样一来，就会出现索引没法使用的状况而形成执行计划问题。

 

9.优先优化高并发的 SQL，而不是执行频率低某些“大”SQL

　　对于破坏性来讲，高并发的 SQL 老是会比低频率的来得大，由于高并发的 SQL 一旦出现问题，甚至不会给咱们任何喘息的机会就会将系统压跨。而对于一些虽然须要消耗大量 IO 并且响应很慢的 SQL，因为频率低，即便遇到，最多就是让整个系统响应慢一点，但至少可能撑一下子，让咱们有缓冲的机会。

 

10.从全局出发优化，而不是片面调整

　　SQL 优化不能是单独针对某一个进行，而应充分考虑系统中全部的 SQL，尤为是在经过调整索引优化 SQL 的执行计划的时候，千万不能顾此失彼，因小失大。

 

11.尽量对每一条运行在数据库中的SQL进行 explain

　　优化 SQL，须要作到心中有数，知道 SQL 的执行计划才能判断是否有优化余地，才能判断是否存在执行计划问题。在对数据库中运行的 SQL 进行了一段时间的优化以后，很明显的问题 SQL 可能已经不多了，大多都须要去发掘，这时候就须要进行大量的 explain 操做收集执行计划，并判断是否须要进行优化。