mysql性能优化建议（一）

Scheme设计与数据类型优化

选择数据类型只要遵循小而简单的原则就好，越小的数据类型一般会更快，占用更少的磁盘、内存，处理时须要的CPU周期也更少。越简单的数据类型在计算时须要更少的CPU周期，好比，整型就比字符操做代价低，于是会使用整型来存储ip地址，使用DATETIME来存储时间，而不是使用字符串。

这里总结几个可能容易理解错误的技巧：

 

1. 一般来讲把可为NULL的列改成NOT NULL不会对性能提高有多少帮助，只是若是计划在列上建立索引，就应该将该列设置为NOT NULL。
2. 对整数类型指定宽度，好比INT(11)，没有任何卵用。INT使用32位（4个字节）存储空间，那么它的表示范围已经肯定，因此INT(1)和INT(20)对于存储和计算是相同的。
3. UNSIGNED表示不容许负值，大体可使正数的上限提升一倍。好比TINYINT存储范围是-128 ~ 127，而UNSIGNED TINYINT存储的范围倒是0 - 255。
4. 一般来说，没有太大的必要使用DECIMAL数据类型。即便是在须要存储财务数据时，仍然可使用BIGINT。好比须要精确到万分之一，那么能够将数据乘以一百万而后使用BIGINT存储。这样能够避免浮点数计算不许确和DECIMAL精确计算代价高的问题。
5. TIMESTAMP使用4个字节存储空间，DATETIME使用8个字节存储空间。于是，TIMESTAMP只能表示1970 - 2038年，比DATETIME表示的范围小得多，并且TIMESTAMP的值因时区不一样而不一样。
6. 大多数状况下没有使用枚举类型的必要，其中一个缺点是枚举的字符串列表是固定的，添加和删除字符串（枚举选项）必须使用ALTER TABLE（若是只只是在列表末尾追加元素，不须要重建表）。
7. schema的列不要太多。缘由是存储引擎的API工做时须要在服务器层和存储引擎层之间经过行缓冲格式拷贝数据，而后在服务器层将缓冲内容解码成各个列，这个转换过程的代价是很是高的。若是列太多而实际使用的列又不多的话，有可能会致使CPU占用太高。
8. 大表ALTER TABLE很是耗时，MySQL执行大部分修改表结果操做的方法是用新的结构建立一个张空表，从旧表中查出全部的数据插入新表，而后再删除旧表。尤为当内存不足而表又很大，并且还有很大索引的状况下，耗时更久。固然有一些奇技淫巧能够解决这个问题，有兴趣可自行查阅。