MySQL数据库优化技巧

1. 优化数据类型

（1）使用小类型的数据类型。小类型的数据在磁盘寻址的时候占用更少的资源，也减少了CPU的运算时间，这样在io wait的时候就不会因为大字段而消耗过多资源。
（2）简单类型优先。比如使用整型存储时间戳；用整型存储IP地址；用整型存储货币浮点，在应用层，再用乘除法换算小数点的精度。
（3）尽量不要使用NULL。对于优化索引，如果字段是NULL，无法对其NULL进行索引排列。不过InnoDB对于NULL是做了特殊的bit位存储。

2. 主键类型的选择

（1）单点使用自增类型的无符号整型。而使用字符串，尤其是随即字符串——UUID，读写性能下降都比较大。
（2）集群中要根据场景视情况而决定是用整型还是UUID。整型比UUID多的步骤就是需要知道全局的主键标示是什么，也就是需要加锁（无论是排他还是读写锁），免不了锁的开销。其他多余的逻辑开销基本没有，而从底层存取来说，随着数据量的增大，整型的优势明显，如果并发量很大，而又是追求吞吐量，UUID优势略微明显。如果数据量也很大，并发量有很大，读多写少的情况，基本上采用整型。如果读写频率相当一致，就该考虑要牺牲一下数据的一致性和准确性保证吞吐量了，那么UUID和整型，基本上在此场景下都差不多了。

3. 字段个数尽量少

存储引擎要想将数据返回给Mysql服务层需要经过数据行缓冲，服务器层要将缓冲的内容解码（因为数据是从存储引擎返回的）为固定的各个列。如果列的个数很多，那么呢，这个数据行转换的代价，比较高！尤其是变长结构——特指myisam和innodb的变长结构，最具代表性，使用频率最高的的——varchar。

4. 关联尽量少

Mysql每个主表关联的操作，只能深到61个从表深度（记住，这里是深度，有点像Java的栈深度，不是广度哦）。《高性能Mysql》的作者们提倡一般关联深度是12层以内。

5. 反范式化

符合范式的优点：

（1）查询的时候，只查询你所关心的表的局部字段数据，而不需要关联的多次IO，去别的表查询关联数据
（2）对于更新操作，只需要关心更改的数据，而不是将整个大表中的某个记录进行行锁定进行更新，其实这里面已经蕴含着分桶，分堆管理的读写分离思想了。
（3）基本上表都是小表，如果不是全局数据集的话，基本上可以放置在数据库的查询缓存中，也就是内存中进行缓存了。
（4）范式化的表，基本上都是按照某种外键进行了分组，相当于在表设计的时候就进行了group by操作。那么查询SQL语句的复杂度，就可以简简单单的根据一个where 外键 = 某值，进行查询。

符合范式的缺点：

（1）其实也是第一个优点的反面case，当一个查询需求需要全字段的数据的时候，不得不多次地随机IO的去关联表去查询整体的实体信息，比如SNS中的用户的profile信息。而反范式的话，那么都在一个表内，基本上都是（小部分不是）顺序IO，磁盘读取数据很快。
（2）关联表越多，索引的工地不过关，那么可能造成关联索引，或者聚合索引失效。
不符合范式的优点与缺点正好是符合范式的颠倒，在此不赘述。

混合范式

实际开发中基本是：根据项目业务场景，范式+反范式=混合范式使用。在产品、项目的不同阶段、数据量不同、用户量不同、并发量不同，会采取不同的混合策略。

6. 牺牲数据时效性，换来高性能

查询一个表的多条记录，用于grid列表展示，那么每个业务基本包含了两个查询事务，一个是用于分页的查询select count记录；另一个用于查询记录的普通select * from操作。随着记录增加，两次查询成本过高，虽然在同一个业务，但是却是两个事务，那么此时数据隐含着已经是有不一致的情况了，所以笔者干脆将count的记录放到了缓存表——memroy中，表名tableinfo，里面仅仅记录了表名，总记录数两个字段，定时任务定时执行select count语句，将结果赋值给该表的记录。
CREATE TABLE tableinfo (
tablename varchar(40) NOT NULL,
datacount int(10) DEFAULT NULL,
PRIMARY KEY (tablename),
UNIQUE KEY tablename (tablename) USING HASH
) ENGINE=MEMORY DEFAULT CHARSET=utf8;
该引擎是memroy，索引键是表名，索引类型，hash。每次启动应用的时候，也会扫描一遍业务表的总记录数，将最新的总记录数赋值给该表的记录。这样，每次执行count就可以从该表进行查询了，只要数据库服务不重启，该汇总表都是有效的。需要说明的是，该汇总信息肯定是牺牲数据的时效性的。

7. 分桶的思想

其实分桶的思想在程序界处处可见，比如Java并发包的并发HashMap。将此思想应用到数据库理论中呢，其实就是读写分离的思想。