那些可能被你忽略的MySQL优化技巧

http://blog.csdn.net/autfish/article/details/51660864

说明：本文中的内容适用于MySQL5.1-5.6版本，不保证新的版本中仍然适用; 且只针对于大部分常见应用场景，是否有效果应以基于实际业务数据的测试为准。

1 优先把列设置为NOT NULL

允许NULL的列不仅占用更多磁盘空间，而且会影响查询分析器对SQL语句的优化，在业务场景允许的情况下应优先设置列为NOT NULL，并赋予默认值如空白字符串、-1等。

2 使用整型代替浮点数类型

DEMICAL有很高的精度，但是计算效率和占用空间上都差于FLOAT、DOUBLE，但是后者不适用于精度非常高的数据。兼顾效率和精度可以把浮点数转换为整型，例如对要求精确到小数点后7位的数据乘以1000000，显示时再通过应用程序做转换。

3 优先把索引设置为唯一

如果已知一个列的内容不会出现重复的行且有必要建立索引，则应建立唯一索引，除了防止误操作，还可以明确的告知查询分析器，某些查询只要找到一条符合条件的记录就可以结束扫描了。

4 使用哈希索引

如果在一个很长的字符串列上做精确查找，直接建立索引可能不是最好的办法，这会导致占用更多磁盘空间和索引效率的降低，例如这个查询

select url from myurls where url='http://blog.csdn.net/autfish/article/details/51660864';

可以考虑从应用层面上优化，对myurls表增加一个int列hashurl，在插入记录时通过一定哈希算法计算url的哈希值，记入hashurl列，并对该列建立索引

查询语句修改为：

select url from myurls where hashurl=3346369 and url='http://blog.csdn.net/autfish/article/details/51660864';

通过hashurl的索引会过滤掉大部分不符合条件的行数，后面的精确匹配解决了哈希冲突问题。

5 使用前缀索引

对于上面这个问题(在很长的字符串列上建索引)，另一个优化选择是只对开头的部分字符建立索引，例如：

alter table myurls add key(url(10));

当然，这个做法对本例是不适合的，因为网址大多数都以http开头，这个索引的大部分内容都起不到过滤的作用。

高性能MySQL书中介绍了一个确定索引字符数的办法，先对列完整内容做group by统计各值分布情况，然后取前n个字符做group by操作，并逐渐增多字符数，直到各值分布的数字与完整内容分布数字接近。

6 反序存储字符串

某些业务场景会频繁以通配符%开头的值做查询条件，例如查询所有qq邮箱用户：

select * ffrom emails where email like '%qq.com'

我们知道这样的查询索引是不起作用的，这时仍然可以在应用层面上解决，对字符串进行反序，例如123@qq.com转换为moc.qq@321，查询语句修改为

select * from emails where email like 'moc.qq@%';

7 使用ENUM类型

例如
create table mytable 
(id int not null auto_increment, 
sex enum('m','f') not null default 'm', 
primary key(id) 
); 
优点是可读性好，(相对于字符串类型)占用空间小
8 把字符串类型转换为整型

某些特殊类型的字符串可以转换为整型存储，常见的有IP和十六进制数形式的字符串，典型的应用是MD5码。

转换IP：

select inet_aton('192.168.0.1');
select inet_ntoa(3232235521);
转换十六进制数：

select hex('a0b1');

select unhex(61306231);
9 使用延迟关联

理解延迟关联的前提是理解覆盖索引，覆盖索引指select的所有列都可以直接在索引中取得，例如：

select name,sex,birthday from users where birthday>'2000-01-01';

如果正好有一个索引是index(name,sex,birthday)，那么执行查询时不需要返回表存储空间读取数据，通常称为覆盖索引，效率非常高。

但是很多时候没有这样的好事，业务上可能需要取出全部字段的十之八九，或者为了方法复用直接select *，这时候可以尝试使用延迟关联：

select * from mytable join(select id from mytable where ...) as t1 on(t1.id=mytable.id)

这是利用了InnoDB的非聚簇索引包含主键的特性对执行计划的一部分使用了索引覆盖，当然，是否能提高执行效率还要看具体业务，不能一概而论。

10 使用explain获得近似值

在海量数据且要做分页的场景中，有时候为了速度会选择用近似值代替完全精确的总数。如何取得近似值呢，用explain命令估算的rows是一个不错的方案。执行explain并不需要真正的执行查询，成本很低。

在总数是近似值时，如何确定是否显示"下一页"按钮呢？我们可以每次在读取下一页内容时都比需要的行数多读一行，例如每页显示20条，每次读取新页内容时读取21条，如果第21条存在则显示下一页，如果不存在（或少于20条）则不显示。