MySQL在大数据、高并发场景下的SQL语句优化和"最佳实践"

　　主要针对中小型应用或网站，重点探讨日常程序开发中SQL语句的优化问题，所谓“大数据”、“高并发”仅针对中小型应用而言，专业的数据库运维大神请无视。以下实践为个人在实际开发工作中，针对相对“大数据”和相对“高并发”场景的一些应对策略，部分措施并没有经过严格的对比测试和原理分析。

　　减少查询的影响结果集，避免出现全表扫描。

　　影响结果集是SQL优化的核心。影响结果集不是查询返回的记录数，而是查询所扫描的结果数。通过Explain或Desc分析SQL，rows列的值即为影响结果集(还可以通过慢查询日志的Rows_examined后面的数字得到)。

　　以下是我常用的一些SQL优化策略：

　　去掉不必要的查询和搜索。其实在项目的实际应用中，很多查询条件是可有可无的，能从源头上避免的多余功能尽量砍掉，这是最简单粗暴的解决方案。

　　合理使用索引和复合索引。建索引是SQL优化中最有效的手段。查找、删除、更新以及排序时常用的字段可以适当建立索引。不过要注意，单条查询不能同时使用多个索引，只能使用一个索引。查询条件较多时，可以使用多个字段合并的复合索引。切记，使用复合索引时，查询条件的字段顺序需要与复合索引的字段顺序保持一致。

　　谨慎使用notin等可能无法使用索引的条件。索引也不是什么时候都可以发挥作用的，当出现"notin"，"!="，"like'%xx%'"，"isnull"等条件时，索引是无效的。使用这些条件的时候，请放到能有效使用索引的条件的右边。设计表结构时，个人建议尽可能用int类型代替varchar类型，int类型部分时候可以通过大于或小于代替"!="等条件，同时也方便满足一些需要按类型排序的需求，至于可读性的问题，完善好数据库设计文档才是明智的选择。同时建议把所有可能的字段设置为"notnull"，并设置默认值，避免在where字句中出现"isnull"的判断。

　　不要在where子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将无法正确使用索引。尽可能少用MySQL的函数，类似Now()完全可以通过程序实现并赋值，部分函数也可以通过适当的建立冗余字段来间接替代。

　　在where条件中使用or，可能导致索引无效。可用"unionall"或者"union"(会过滤重复数据，效率比前者低)代替，或程序上直接分开两次获取数据再合并，确保索引的有效利用。

　　不使用select*，倒不是能提高查询效率，主要是减少输出的数据量，提高传输速度。

　　避免类型转换，这里所说的“类型转换”是指where子句中出现字段的类型和传入的参数类型不一致的时候发生的类型转换。

　　分页查询的优化。页数比较多的情况下，如limit10000,10影响的结果集是10010行，查询速度会比较慢。推荐的解决方案是：先只查询主键selectidfromtablewhere..orderby..limit10000,10(搜索条件和排序请建立索引)，再通过主键去获取数据。

　　统计相关的查询。影响结果集往往巨大，且部分SQL语句本身已经难以优化。因此，应避免在业务高峰期执行统计相关的查询，或者仅在从库中执行统计查询。部分统计数据，可以通过冗余的数据结构保存，同时建议把数据先保存在内存、缓存中(如redis)，再按一定策略写入数据库。

不使用任何连表查询，通过分库和分表实现负载均衡。