最近一直在忙工作的事情，也有点懒，不想写，划水了好多天了，今天就水文一篇，聊聊积累的一些mysql的优化经验。
大部分的游戏数据库都是使用mysql,开源，免费是他的法宝，虽然没有oracle牛逼，但是对于日常的使用，完全够用，所以大多的公司都是使用mysql作为数据的落地选择，因为之前一直使用的InnoDB引擎，所以今天今天大概聊一下对数据库的优化原则问题，都是基于InnoDB引擎，希望你能在遇到同样的问题时能解决问题。OK，我们开始吧。
1、查询语句的执行顺序
select[distinct]fromjoin（如leftjoin）onwheregroupbyhavingunionorderbylimit
执行顺序:fromwhere聚havingorderlimit
1、from先做表连接
2、where进行条件限制
3、然后做聚合groupby
4、然后做having过滤
5、然后对结果进行排序
6、最后限制数量limit
sql的查询执行顺序我想有些人还是记不住的，我的建议就是自己整理一个简单的记忆短句，然后反复阅读，直至记住，下次再遇到问题的时候自己回想下自己记忆的短句，能解决问题就行了，死记硬背就好，尽量简短。
2、数据类型的选择
更小的数据类型通常更好：因为更好的存储空间
简单数据类型
尽量避免NULL：含NULL复合索引无效.可为NULL的列会使用更多的存储空间，在Mysql中也需要特殊处理。
TIMESTAMP空间利用比DATETIME小的多，比整形方便处理，整形不会带来任何好处。
IPV4的地址，经常使用VARCHAR(15)来存储。然而它实际是32为无符号整数，不是字符串。用小数点将地址分成四段只是为了让人们容易阅读。
对象关系映射（ORM）系统（以及使用它们的“框架”）通常都是低效的，一些ORM系统会存储任意类型的数据到任意类型的后端数据存储中。这种设计对开发者很有吸引力，因为这使得开发者可以用面向对象的方式工作，不需要考虑数据是怎么存储的。
原则：尽可能小（占用存储空间少）、尽可能定长（占用存储空间固定）、尽可能使用整数。
3、索引优化
主键索引
InnoDB通过主键聚集数据，数据按主键顺序存储，更新主键索引列的代价很高，因为会强制InnoDB将每个被更新的行移动到新的位置
多列索引
一个常见的错误就是为每个列创建单独的索引，这种错误的认知一般都是听了“把where条件里面的列都建上索引”这样模糊的建议导致的。
实际上，在多个列上建立独立的索引大部分情况下都不能提高mysql的查询性能，有时反而会使查询变的更慢。
因为索引需要额外的空间记录，在查询到时候如果索引使用不当，需要同时加载索引和数据，会造成查询慢。
注意：索引列的顺序
正确的顺序依赖于使用该索引的查询，并且同时需要考虑如何更好地满足排序和分组的需要
一般性的经验法则：
1、将选择性最高的列放在最前面
2、在查询的时候不要对索引列进行函数操作
3、尽可能的使用索引
4、查询性能优化
1、查询的生命周期
客户端-服务器查询缓存-解析器-预处理器-查询优化器-查询执行引擎-存储引擎-数据
尽量命中缓存，尽量少读数据，尽量少查数据。
2、SELECT语句尽量指明查询字段名称
select*会增加不必要的消耗，如果使用的字段很少，会导致读取的数据量变多，网络传输也会变慢，消耗cpu，所以selectcount(1)优于selectcount(*)在表进行修改的时候，代码里的查询字段可能会忘记修改，导致代码报错，是安全隐患。3、小表驱动大表
尽量少的关联数据读取，数据量越少越快，
注意：副表不存在的数据是null
优化数据访问原则：
1、是否向数据库请求了不需要的数据，减少数据加载和网络传输
2、查询是否扫描了大量不需要的记录（返回的行数/扫描的行数），降低读取数据的时间
总结
使用小而简单的合适的数据类型，尽量避免NULL
避免过度设计，例如会导致复杂查询的schema设计
合理混用范式化和反范式化设计，以空间换时间，适当的冗余带来速度
单行访问是很慢的，最好读取的数据块中能包含尽可能多所需要的行
按顺序访问范围数据是很快的
当数据量逐渐增大时，不恰当的索引会导致性能急剧下降
要想写一个好的查询，必须要理解schema设计、索引设计等知识。他们之间环环相扣，密不可分。只有综合考虑各方需
求，权衡利弊，才能设计出一个高性能的数据库系统。
原则：做的越少越好，最好不做
常规福利