MySQL查询性能优化

MySQL数据库配置参数建议如下：

• 建议设置default-storage-engine=InnoDB,一般不建议使用MyISAM引擎
• 调整InnoDB_buffer_pool_size的大小，如果是单实例且绝大多数是InnoDB引擎表的话，可考虑设置为物理内存的50%~70%
• 设置InnoDB_file_per_table=1，使用独立表空间
• 调整InnoDB_data_file_path=ibdata1:1G:autoextend，不要用默认的10M，在高并发场景下，性能会有很大提升
• 设置InnoDB_log_file_size=256M，设置InnoDB_log_file_in_group=2，基本可以满足大多数应用场景
• 调整max_connection(最大连接数)、max_connection_errOR(最大错误数)设置，根据业务量大小进行设置
• open_files_limit、InnoDB_open_files、table_open_cache、table_definition_cache可以设置大约为max_connection的10倍
• key_buffer_size建议调小，32M即可，另外建议关闭query cache
• mp_table_size和max_heap_table_size设置不要过大，另外sORt_buffer_size、join_buffer_size、read_buffer_size、read_rnd_buffer_size等设置也不要过大

MySQL字段设计原则

• 当数据存储的是字符，且长度是一个固定区间定值的话就可以考虑使用CHAR来进行存储。如果字符长度是未知的且长度变化特别明显的话，这个时候最好使用VARCHAR来存储。但是不管使用的是哪种字段来进行存储，都不要把字段的初始长度设置为最大化，应该是根据业务需求来存储最合适长度的字段。
• 数据库设计过程中尽量用int来作为字段类型，因为在所有的数据类型中int不管是存储空间还是执行速度都是最好的。
• 在涉及金额的时候，如果对精度要求不高的情况下可以优先使用float，其次是使用double进行存储。如果对精度要求比较高的情况下，则使用decimal来存储，但是decimal的效率没有float和double那么高效。
• int(1)和int(10)的区别是？1和10只是设定其显示的长度，也就是不管int(x)的这个x值是什么，存储数字的取值范围还是int本身数据类型所决定的，不受其显示长度的影响

MySQL索引

索引分为聚簇索引和非聚簇索引两种，聚簇索引是按照数据存放的物理位置为顺序的，所以聚簇索引能提高多行检索的速度，非聚簇索引对于单行的检索速度非常快。

什么样的字段适合创建索引

• 在经常需要搜索的列上加索引可以加快搜索速度；
• 在作为主键的列上，强制该列的唯一性和组织表中数据的排列结构；
• 在经常用在连接的列上，这些列主要是一些外键，可以加快连接的速度；
• 在经常需要根据范围进行搜索的列上创建索引，因为索引已经排序，其指定的范围是连续的；
• 在经常需要排序的列上创建索引，因为索引已经排序，这样查询可以利用索引排序，加快排序查询时间；
• 在经常使用在where子句中的列上面加索引，加快条件的判断速度
• 建立索引一般按照SELECT的WHERE条件来建立，如如果条件是WHERE f1 AND f2，那么如果字段f1或f2上建立索引是没用的，只有在字段f1和f2上同时建立索引才有用

什么样的字段不适合创建索引

• 对于那些在查询中很少使用或参考的列不应该创建索引。因为既然这些列很少使用到，因此有索引或者无索引，并不能提高查询速度。相反，由于增加了索引，反而降低了系统的维护速度和增大了空间需求。
• 对于那些只有很少数据值的列也不应该增加索引，因为由于列的取值很少，在查询的结果中，结果集的数据行占了表中数据行的很大比例，即需要在表中搜索的数据行的比例很大，加索引并不能明显加快检索速度。
• 对于定义为text，image和bit数据类型的列不应该增加索引，因为这些列的数据量要么相当大，要么取值很少。
• 当修改需求远远大于检索需求时不应该创建索引。因为修改和检索是相互矛盾的。当增加索引时，会提高检索性能，但是会降低修改性能。

MySQL查询优化

• 对查询进行优化，应尽量避免全表扫描，首先应考虑在WHERE及ORDER BY涉及的列上建立索引。
• 应尽量避免在WHERE子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描
• 应尽量避免在WHERE子句中对字段进行NULL值判断，否则将导致引擎放弃使用索引而进行全表扫描。例如SELECT id FROM t WHERE num IS NULL.可以在num上设置默认值0,确保num列没有NULL值
• 应尽量避免在WHERE子句中使用OR来连接条件，否则将导致引擎放弃使用索引而进行全表扫描。

例如：

• 可以用UNION ALL代替OR

SELECT id FROM t WHERE num=10 OR num=20;

改为

SELECT id FROM t WHERE num=10
UNION ALL
SELECT id FROM t WHERE num=20

• 下面的查询也将导致全表扫描

SELECT id FROM t WHERE name like '%abc%';
SELECT id FROM t WHERE num in (1,2,3);

• 对于连续的数值，能用BETWEEN就不要用in

SELECT id FROM t WHERE num between 1 AND 3;

• 如果在WHERE子句中使用参数，也会导致全表扫描，

SELECT id FROM t WHERE num=@num;

改为强制查询使用索引：

SELECT id FROM t with(INDEX(索引名)) WHERE num=@num;

• 应尽量避免在WHERE子句中对字段进行表达式操作，这将放弃使用索引而进行全表扫描

SELECT id FROM t WHERE num/2=100;

改为

SELECT id FROM t WHERE num=100*2;

• 不要在WHERE子句的=左边进行函数、算术运算或其他表达式运算，否则系统将无法正确使用索引。

• 在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能地让字段顺序与索引顺序相一致。

• 很多时候用exists代替in

SELECT num FROM a WHERE num IN (SELECT num FROM b);

替换为

SELECT num FROM a WHERE EXISTS(SELECT 1 FROM b WHERE num=a.num);

• 并不是所有的索引对查询都有效，SQL语句是根据表中数据来进行查询优化的，当索引列有大量的数据重复时，SQL查询可能不会去利用索引。

• 索引并不是越多越好，索引虽然可以提高相应的SELECT的效率，但同时也降低了INSERT和UPDATE的效率，所以怎样建立索引需要慎重考虑，视具体情况而定，一个表的索引数量最好不要超过6个，若太多则考虑那些不常使用列上的索引是否有必要。

• 尽量使用数字型字段，若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销。

• 任何地方都不要使用SELECT * FROM，用具体的字段列表代替*,不要返回用不到的任何字段。

• 尽量避免使用游标，因为游标的效率较差，如果游标操作的数据超过1万行，那么就应该考虑改写。

MySQL EXPLAIN

关于EXPLAIN返回结果集参数解析

列	值	解释
id		查询序号即为SQL语句执行的顺序，顺序号越大越先执行，相同的顺序号，从上到下顺序执行
select_type	simple	它表示简单的SELECT，没有UNION和子查询
	primary	最外面的SELECT，在有子查询的语句中，最外面的SELECT查询就是primary
	UNION	UNION中的第二个或后面的SELECT语句，取决于外面的查询
	UNION RESULT	UNION的结果
type	system	查询出的数据仅有一行，这是const类型的特例，平时不会出现
	const	表最多有一个匹配行，const用于比较primary key或者unique索引。因为只匹配一行数据，所以速度很快。const的出现，说明一定是用到primary key或者unique，可以理解为const是最优的
	eq_ref	对于每个来自于前面的表的行组合，从该表中读取一行。这可能是最好的联接类型，除了const类型。它用在一个索引的所有部分被联接使用并且索引是UNIQUE或PRIMARY KEY
	ref	对于每个来自于前面的表的行组合，所有存在匹配索引值的行将从这张表中读取，如果联接只使用键的最左边的前缀，或如果查询的键（查询条件中的关键字）不是UNIQUE或PRIMARY KEY（如果联接不能基于关键字选择单个行的话），则使用ref
	ref_or_null	该联接类型如同ref，增添了可以专门搜索包含NULL值的行
	index_merge	该联接类型表示使用了索引合并优化方法。在这种情况下，key列包含了使用的索引的清单，key_len包含了使用的索引的最长的关键元素
	unique_subquery
	index_subquery	如果出现这个就更糟糕了
	range	给定范围内的检索
	index	该联接类型与ALL相同，除了只有索引树被扫描。这通常比ALL快，因为索引文件通常比数据文件小。(虽然all和INDEX都是读全表，但INDEX是从索引中读取，而all是从硬盘中读取)当查询只使用作为单索引一部分的列时，MySQL可以使用该联接类型
	ALL	对于每个来自于先前的表的行组合，进行完整的表扫描。如果表是第一个没标记const的表，在通常情况下会很差。但可以增加更多的索引而不要使用ALL，使得行能基于前面的表中的常数值或列值被检索
possible_keys		提示使用哪个索引会在该表中找到行，不重要
keys		MySQL使用的索引，简单且重要
key_len		MySQL使用的索引长度
ref		显示使用哪个列或常数与key一起从表中选择行
rows		显示MySQL执行查询的行数，简单且重要，数值越大越不好，说明没有用好索引
extra	distinct	MySQL发现第1个匹配行后，停止为当前的行组合搜索更多的行
	not exists
	range checked for each record	没有找到合适的索引
	using filesort	MySQL需要额外一次传递，以找出如何按排序顺序检索行。通过根据联接类型浏览所有行为所有匹配WHERE子句的行保存排序关键字和行的指针来完成排序。然后关键字被排序，并按排序顺序检索行
	using index	只使用索引树中的信息而不需要进一步搜索读取实际的行来检索表中的信息
	using temporary	为了解决查询，MySQL需要创建一个临时表来容纳结果。典型情况如查询包含可以按不同情况列出列的GROUP BY和ORDER BY子句时。出现using temporary就说明语句需要优化了
	using where	WHERE子句用于限制哪一个行匹配下一个表。除非专门从表中索取或检查所有行，如果extra值不是using where并且表联接类型为ALL或INDEX，查询可能会有一些错误。如果想要使查询尽可能快，应找出using filesort和using temporary的extra值
	using sort_union(...),using union(...),using intersect(...)	这些函数说明如何为index_merge联接类型合并索引扫描
	using index for group-by	类似于访问表的using index方式，using index for group-by表示MySQL发现了一个索引，可以用来查询GROUP BY或DISTINCT的所有列，而不要额外搜索硬盘访问实际的表。并且，按最有效的方式使用索引，以便对于每个组，只读取少量索引条目