如今随着互联网的发展，数据的量级也是撑指数的增长，从GB到TB到PB。对数据的各种操作也是愈加的困难，传统的关系性数据库已经无法满足快速查询与插入数据的需求。这个时候NoSQL的出现暂时解决了这一危机。它通过降低数据的安全性，减少对事务的支持，减少对复杂查询的支持，来获取性能上的提升。但是，在有些场合NoSQL一些折衷是无法满足使用场景的，就比如有些使用场景是绝对要有事务与安全指标的。这个时候NoSQL肯定是无法满足的，所以还是需要使用关系性数据库。
虽然关系型数据库在海量数据中逊色于NoSQL数据库，但是如果你操作正确，它的性能还是会满足你的需求的。针对数据的不同操作，其优化方向也是不尽相同。对于数据移植，查询和插入等操作，可以从不同的方向去考虑。而在优化的时候还需要考虑其他相关操作是否会产生影响。就比如你可以通过创建索引提高查询性能，但是这会导致插入数据的时候因为要建立更新索引导致插入性能降低，你是否可以接受这一降低那。所以，对数据库的优化是要考虑多个方向，寻找一个折衷的最佳方案。
一：查询优化
1：创建索引。
最简单也是最常用的优化就是查询。因为对于CRUD操作，read操作是占据了绝大部分的比例，所以read的性能基本上决定了应用的性能。对于查询性能最常用的就是创建索引。经过测试，2000万条记录，每条记录200字节两列varchar类型的。当不使用索引的时候查询一条记录需要一分钟，而当创建了索引的时候查询时间可以忽略。但是，当你在已有数据上添加索引的时候，则需要耗费非常大的时间。我插入2000万条记录之后，再创建索引大约话费了几十分钟的样子。
创建索引的弊端和场合。虽然创建索引可以很大程度上优化查询的速度，但是弊端也是很明显的。一个是在插入数据的时候，创建索引也需要消耗部分的时间，这就使得插入性能在一定程度上降低；另一个很明显的是数据文件变的更大。在列上创建索引的时候，每条索引的长度是和你创建列的时候制定的长度相同的。比如你创建varchar(100)，当你在该列上创建索引，那么索引的长度则是102字节，因为长度超过64字节则会额外增加2字节记录索引的长度。
从上图可以看到我在YCSB_KEY这一列(长度100)上创建了一个名字为index_ycsb_key的索引，每条索引长度都为102，想象一下当数据变的巨大无比的时候，索引的大小也是不可以小觑的。而且从这也可以看出，索引的长度和列类型的长度还不同，比如varchar它是变长的字符类型(请看MySQL数据类型分析)，实际存储长度是是实际字符的大小，但是索引却是你声明的长度的大小。你创建列的时候声明100字节，那么索引长度就是这个字节再加上2，它不管你实际存储是多大。
除了创建索引需要消耗时间，索引文件体积会变的越来越大之外，创建索引也需要看的你存储数据的特征。当你存储数据很大一部分都是重复记录，那这个时候创建索引是百害而无一利。请先查看MySQL索引介绍。所以，当很多数据重复的时候，索引带来的查询提升的效果是可以直接忽略的，但是这个时候你还要承受插入数据的时候创建索引带来的性能消耗。
2：缓存的配置。
在MySQL中有多种多样的缓存，有的缓存负责缓存查询语句，也有的负责缓存查询数据。这些缓存内容客户端无法操作，是由server端来维护的。它会随着你查询与修改等相应不同操作进行不断更新。通过其配置文件我们可以看到在MySQL中的缓存：
在这里主要分析query cache，它是主要用来缓存查询数据。当你想使用该cache，必须把query_cache_size大小设置为非0。当设置大小为非0的时候，server会就会缓存每次查询返回的结果，到下次相同查询server就直接从缓存获取数据，而不是再执行查询。能缓存的数据量就和你的size大小设置有关，所以当你设置的足够大，数据可以完全缓存到内存，速度就会非常之快。
但是，query cache也有它的弊端。当你对数据表做任何的更新操作(update/insert/delete)等操作，server为了保证缓存与数据库的一致性，会强制刷新缓存数据，导致缓存数据全部失效。所以，当一个表格的更新数据表操作非常多的话，query cache是不会起到查询提升的性能，还会影响其他操作的性能。
3：slow_query_log分析。
其实对于查询性能提升，最重要也是最根本的手段也是slow_query的设置。
当你设置slow_query_log为on的时候，server端会对每次的查询进行记录，当超过你设置的慢查询时间(long_query_time)的时候就把该条查询记录到日志。而你对性能进行优化的时候，就可以分析慢查询日志，对慢查询的查询语句进行有目的的优化。可以通过创建各种索引，可以通过分表等操作。那为什么要分库分表那，当不分库分表的时候那个地方是限制性能的地方啊。下面我们就简单介绍。
4：分库分表
分库分表应该算是查询优化的杀手锏了。上述各种措施在数据量达到一定等级之后，能起到优化的作用已经不明显了。这个时候就必须对数据量进行分流。分流一般有分库与分表两种措施。而分表又有垂直切分与水平切分两种方式。下面我们就针对每一种方式简单介绍。
对于mysql，其数据文件是以文件形式存储在磁盘上的。当一个数据文件过大的时候，操作系统对大文件的操作就会比较麻烦与耗时，而且有的操作系统就不支持大文件，所以这个时候就必须分表了。另外对于mysql常用的存储引擎是Innodb，它的底层数据结构是B+树。当其数据文件过大的时候，B+树就会从层次和节点上比较多，当查询一个节点的时候可能会查询很多层次，而这必定会导致多次IO操作进行装载进内存，肯定会耗时的。除此之外还有Innodb对于B+树的锁机制。对每个节点进行加锁，那么当更改表结构的时候，这时候就会树进行加锁，当表文件大的时候，这可以认为是不可实现的。
所以综上我们就必须进行分表与分库的操作。
5：子查询优化
在查询中经常会用到子查询，在子查询的时候一般使用in或者exist关键词。针对in和exist在查询的时候当数据量大到一定程度以后，查询执行时间就差别比较大。但是，为了避免此类情况出现，最好的方式是使用join查询。因为在绝大多数情况下，服务器对join的查询优化要远远高于子查询优化。在比较高的版本5.6，mysql查询会自动把in查询优化成joint查询，就不会出现子查询比较慢的问题。有时候也可以采用distinct关键词来限制子查询的数量，但是需要注意的是distinct很多时候会转化为group by，这个时候就会出现一个
临时表，就会出现copy数据到临时表的时延。
二：数据转移
当数据量达到一定等级之后，那么移库将是一个非常慎重又危险的工作。在移库中保证前后数据的一致性，各种突发情况的处理，移库过程中数据的变迁，每一个都是一个非常困难的问题。
2.1：插入数据
当进行数据迁移的时候，肯定会存在大数据的重新导入，你可以选择直接load文件，有的时候可能就需要代码插入了。这个时候就需要对插入语句进行一定的优化了。这个时候可以使用INSERT DELAYED语句，该语句是当你发出插入请求的时候，不是马上就插入到数据库而是放在缓存里面，等待时机成熟之后再进行插入。
1、对查询进行优化、应尽量避免全表扫描、首先应考虑在 where 及 order by 涉及的列上建立索引。
2、应尽量避免在 where 子句中对字段进行 null 值判断、否则将导致引擎放弃使用索引而进行全表扫描、如：
select id from t where num is null;
--可以在num上设置默认值0、确保表中num列没有null值、然后这样查询：
select id from t where num=0;
3、应尽量避免在 where 子句中使用!=或<>操作符、否则将引擎放弃使用索引而进行全表扫描。
4、应尽量避免在 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;
5、in 和 not in 也要慎用、否则会导致全表扫描、如：
select id from t where num in(1,2,3);
对于连续的数值、能用 between 就不要用 in 了：
select id from t where num between 1 and 3;
6、下面的查询也将导致全表扫描：
select id from t where name like '%abc%';
--若要提高效率、可以考虑全文检索。
7、如果在 where 子句中使用参数、也会导致全表扫描。因为SQL只有在运行时才会解析局部变量、但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。然而、如果在编译时建立访问计划、变量的值还是未知的、因而无法作为索引选择的输入项。如下面语句将进行全表扫描：
select id from t where num=
@num ;
--可以改为强制查询使用索引：
select id from t with(index(索引名)) where num=
@num ;
8、应尽量避免在 where 子句中对字段进行表达式操作、这将导致引擎放弃使用索引而进行全表扫描。如：
select id from t where num/2=100;
--应改为:
select id from t where num=100*2;
9、应尽量避免在where子句中对字段进行函数操作、这将导致引擎放弃使用索引而进行全表扫描。如：
select id from t where substring(name,1,3)='abc';
--name以abc开头的id
select id from t where datediff(day,createdate,'2005-11-30')=0;
--‘2005-11-30’生成的id
--应改为:
select id from t where name like 'abc%';
select id from t where createdate>='2005-11-30' and createdate<'2005-12-1';
10、不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算、否则系统将可能无法正确使用索引。
11、在使用索引字段作为条件时、如果该索引是复合索引、那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引、否则该索引将不会被使用、并且应尽可能的让字段顺序与索引顺序相一致。
12、不要写一些没有意义的查询、如需要生成一个空表结构：
select col1,col2 into #t from t where 1=0;
--这类代码不会返回任何结果集、但是会消耗系统资源的、应改成这样：
create table #t(...);
13、很多时候用 exists 代替 in 是一个好的选择：
select num from a where num in(select num from b);
--用下面的语句替换：
select num from a where exists(select 1 from b where num=a.num);
14、并不是所有索引对查询都有效、SQL是根据表中数据来进行查询优化的、当索引列有大量数据重复时、SQL查询可能不会去利用索引、如一表中有字段sex、male、female几乎各一半、那么即使在sex上建了索引也对查询效率起不了作用。
15、索引并不是越多越好、索引固然可以提高相应的 select 的效率、但同时也降低了 insert 及 update 的效率、因为 insert 或 update 时有可能会重建索引、所以怎样建索引需要慎重考虑、视具体情况而定。一个表的索引数最好不要超过6个、若太多则应考虑一些不常使用到的列上建的索引是否有必要。
16、应尽可能的避免更新 clustered 索引数据列、因为 clustered 索引数据列的顺序就是表记录的物理存储顺序、一旦该列值改变将导致整个表记录的顺序的调整、会耗费相当大的资源。若应用系统需要频繁更新 clustered 索引数据列、那么需要考虑是否应将该索引建为 clustered 索引。
17、尽量使用数字型字段、若只含数值信息的字段尽量不要设计为字符型、这会降低查询和连接的性能、并会增加存储开销。这是因为引擎在处理查询和连接时会逐个比较字符串中每一个字符、而对于数字型而言只需要比较一次就够了。
18、尽可能的使用 varchar/nvarchar 代替 char/nchar 、因为首先变长字段存储空间小、可以节省存储空间、其次对于查询来说、在一个相对较小的字段内搜索效率显然要高些。
19、任何地方都不要使用 select * from t 、用具体的字段列表代替“*”、不要返回用不到的任何字段。
20、尽量使用表变量来代替临时表。如果表变量包含大量数据、请注意索引非常有限（只有主键索引）。
21、避免频繁创建和删除临时表、以减少系统表资源的消耗。
22、临时表并不是不可使用、适当地使用它们可以使某些例程更有效、例如、当需要重复引用大型表或常用表中的某个数据集时。但是、对于一次性事件、最好使用导出表。
23、在新建临时表时、如果一次性插入数据量很大、那么可以使用 select into 代替 create table、避免造成大量 log 、以提高速度；如果数据量不大、为了缓和系统表的资源、应先create table、然后insert。
24、如果使用到了临时表、在存储过程的最后务必将所有的临时表显式删除、先 truncate table 、然后 drop table 、这样可以避免系统表的较长时间锁定。
25、尽量避免使用游标、因为游标的效率较差、如果游标操作的数据超过1万行、那么就应该考虑改写。
26、使用基于游标的方法或临时表方法之前、应先寻找基于集的解决方案来解决问题、基于集的方法通常更有效。
27、与临时表一样、游标并不是不可使用。对小型数据集使用 FAST_FORWARD 游标通常要优于其他逐行处理方法、尤其是在必须引用几个表才能获得所需的数据时。在结果集中包括“合计”的例程通常要比使用游标执行的速度快。如果开发时间允许、基于游标的方法和基于集的方法都可以尝试一下、看哪一种方法的效果更好。
28、在所有的存储过程和触发器的开始处设置 SET NOCOUNT ON 、在结束时设置 SET NOCOUNT OFF 。无需在执行存储过程和触发器的每个语句后向客户端发送 DONE_IN_PROC 消息。
29、尽量避免大事务操作、提高系统并发能力。
30、尽量避免向客户端返回大数据量、若数据量过大、应该考虑相应需求是否合理。
