1、从内存中读取数据是微秒级别的。而从磁盘读则是毫秒级别的。二者相差一个数量级。所以想优化数据库，第一个要做到的就是优化io。
2、key_buffer_size[global]设置的内存区域大小缓存了myisam表的索引。由于myisam只缓存索引在内存中，并不缓存数据在内存，所以如果内存允许，要让这个参数足够能容纳所有myisam的所有索引来提高性能。另外，在myisam表上，尽量让所有的查询条件都限制在索引上，以便能让缓存替我们提高查找效率。
3、bulk_insert_buffer_size[thread]仅仅用在myisam中，用于在插入数据的时候临时缓存数据。当我们使用如下的写入语句的时候，会使用这个内存区域帮助批量写入数据文件：
insert ... select ...
insert into ... values ...
load data infile ... into ...
4、innodb_buffer_pool_size[global]当我们使用innodb引擎的时候这个参数也许是影响性能最为关键的一个参数了。它用来设置缓存innodb的索引以及数据块的内存区域大小。
简单来说，我们操作innodb表的时候，返回的所有数据以及去查找数据的过程中所用到的所有索引，都会在这个内存块中走一遭。
5、innodb_additional_mem_pool_size[global]设置了innodb存储引擎用来存放数据字典信息以及一些内部数据结构的内存区域大小。所以，当我们一个mysql instance中
包含有很多数据库对象（比如很多表的时候）的时候需要适当调整该参数的大小以确保所有的数据都在内存中，以确保效率。这个参数的内存是否足够还是比较容易知道的。因为当过小的时候
mysql会记录warning到error log中的。
6、innodb_log_buffer_size[global]innodb事务所使用的内存。innodb在写事务日志的时候，为了提高性能，先写入缓存，再写到logfile中。
7、innodb_max_dirty_pages_pct[global]用来控制在innodb的buffer pool中，可以不用写入数据文件的dirty page(已经被修改，但是还没写入到数据文件的脏数据)的比例。
这个值越大，从内存到磁盘的写入操作就会减少。所以能够一定程度减少磁盘io。但是当这个值很大的时候，如果数据库crash，那么重启的时间可能就会很长。因为会有
大量的事务数据需要从日志文件中恢复出来写入到数据文件中。同时，过大的比例值，也会造成当达到比例设定的上限之后，flush操作写入数据“过猛”，造成性能波动剧烈。
8、当我们要取出全表大部分的数据的时候 ，索引扫描不一定优于全表扫描。
9、mysql是基于行的数据库，而数据读取则是基于page的。每个page中存放有行。如果每一行的数据量都减小，那么每个page里面存放的行就增多了。每次io就能偶取出更多的行。
反过来，处理相同的数据，处理的page就会减少。也即是io次数的降低。直接提升性能。此外，由于我们的内存数量是有限的，那么每个page中行数增多了，就等于增加了
每个数据块的缓存数据量，也能够提升命中率。
10、我们无法改变要存储什么数据，但是怎么存储数据我们可以花一些心思。
1）数字类型。万不得已，不要用double类型。除了占用空间比较大之外，还有精度问题。同样，固定精度的小数也不要使用decimal，建议乘以固定倍数，转换成整数进行存储。
可以节省存储空间，而且不用任何附加维护成本。对于整数的存储，建议分开tinyint/int/bigint，他们存储数据占用空间有一定差距。
2）字符类型。万不得已，不要用text类型。它的处理效率低于char和varchar。定长字段建议char类型。变长用varchar。varchar切不可以随意给一个很大的长度。因为不一样的长度范围，mysql会有不同的处理。在博客中有一篇是介绍varchar的处理方式的。假设声明了varchar(1000)，那么，mysql在磁盘中存储这个数据的时候，假设数据长度45，那么磁盘中就占用大概45左右的空间。但是当这个数据在内存中的时候还是要占用1000个空间的。浪费了很多。
3）事件类型。尽量使用timestamp。存储空间占用只是datetime类型的一半。对于需要精确到某一天的类型，建议使用date类型。因为它存储需要三个字节。比timestamp还少。
不建议使用int来存储一个unix timestamp，不直观，不会带来任何好处。
4）适当对表中字段进行冗余。比如说，把一个文章的摘要，与文章信息表放在一起，而不是跟文章详细内容表放在一起。

mysql内存使用以及优化中需要的几点注意