MySQL在大数据、高并发场景下的SQL语句优化和实践是怎样的

共计 1547 个字符，预计需要花费 4 分钟才能阅读完成。

MySQL 在大数据、高并发场景下的 SQL 语句优化和实践是怎样的，很多新手对此不是很清楚，为了帮助大家解决这个难题，下面丸趣 TV 小编将为大家详细讲解，有这方面需求的人可以来学习下，希望你能有所收获。

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)，再按一定策略写入数据库。

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

看完上述内容是否对您有帮助呢？如果还想对相关知识有进一步的了解或阅读更多相关文章，请关注丸趣 TV 行业资讯频道，感谢您对丸趣 TV 的支持。