数据库作为应用开发中必不缺少的基础设施，其性能直接影响应用的整体运行速度。MySQL是目前最广泛使用的关系型数据库之一，对于开发人员写出性能良好的SQL是必备的基本技能之一。下面简单描述下编写SQL的注意事项。
编写高质量的SQL需要从以下几个方面注意，基本原则、表字段注意事项、索引使用注意事项、SQL注意事项。
基本原则
一、尽量不要在数据库里做运算。如果遇到运算尽可能在应用程序层进行计算。
二、控制数据库表数量、控制单表数据量、控制表的字段数。建议单库不要超过四百张表，建议单表字段不要超过五十个，建议单表的数据量不要超过一千万。
三、不要编写大SQL、不要使用大事务。SQL尽量写的简单点拒绝编写大SQL，可以将大SQL拆分成多个小SQL，在应用层聚合。大事务拆分成多个小事务，快速提交。
表字段注意事项
一、选择合适数值字段类型。能用小字段类型的就用小字段类型，如tinyint就比int(1)在表示小数据时合适。
二、能用数字表示就不要用字符。如可以用无符号INT存储IP而不是字符串表示。
三、避免使用NULL字段。原因NULL字段查询优化难，含NULL复合索引失效。
四、少用或拆分TEXT/BLOB字段。字段太大需要更多的空间，性能低下，如需使用拆分到单独表。
五、不要在表字段中存储图片。
索引使用注意事项
一、合理添加索引。索引添加太多会影响更新速度。能够使用复合索引的避免加多个单独索引。
二、字符字段建立前缀索引。
三、不在索引列做运算。索引列做运算会导致索引失效。
四、尽量不使用外建。
SQL类注意事项
一、 SQL语句尽可能简单。大SQL拆分成多个小SQL。
二、事务编写尽量短小。事务即开即用用完立即关闭。
三、尽量不要使用select *。只取需要的列。
四、改写OR为IN或者改写为UNION操作。OR在数据量大的时候性能低于IN。
五、避免NOT、!=、>、NOT IN、NOT EXISTS、NOT LIKE等查询。
六、避免%前缀模糊查询。
七、能用UNION ALL不要用UNION。
八、GROUP BY中去除排序。自带排序。
九、同类型的字段做比较。字符类和字符类比较，数值类和数值类比较，不要混在一起比较。
十、尽量单表查询，尽量不要多表关联查询。多表关联查询可以拆分成单表查询在应用程序中聚合数据。
十一、复合索引的多列注意最左原则。
上述注意事项能避免很多性能低下的SQL，希望在开发过程中能引起注意。
荐书-MySQL是怎样运行的
第一种：MySQL 随机排序常规写法：展开目录
SELECT*FROMusersWHEREtotalScoreBETWEEN5AND100ORDERBYRAND()LIMIT100
执行耗时 1.18s
SELECT*FROMusersWHEREtotalScoreBETWEEN5AND100ORDERBYRAND()LIMIT100
执行耗时 1.25s
这样的耗时不能接受。
第二种：stackoverflow 上找了一个黑科技写法：展开目录
SELECT*FROMusersWHEREtotalScoreBETWEEN5AND100ORDERBY37*(UNIX_TIMESTAMP() ^id) &0xffffLIMIT100
执行耗时 150ms
SELECT*FROMusersWHEREtotalScoreBETWEEN5AND100ORDERBY37*(UNIX_TIMESTAMP() ^id) &0xffffLIMIT100
执行耗时 153ms
执行耗时直接缩短至 150ms，已经比上一个写法快很多了，而且 LIMIT 1000 时耗时也是 150ms 左右。
第三种方式：展开目录
SELECT*
FROMusersASu
INNERJOIN(SELECTidFROMusersWHEREtotalScoreBETWEEN5AND100ORDERBYRAND()LIMIT100)AStONt.id=u.id
WHERE1
执行耗时 110ms
LIMIT 1000 时耗时也稳定在 110ms 左右。
耗时最少，推荐使用第三种。
MySQL的limit 优化
推荐一个讲解MySQL的好书– MySQL是怎样运行的 ,作者是小孩子4919,这是目前为止笔者读过的MySQL方面最好的书.
笔者之前翻看过(MySQL技术内幕：InnoDB存储引擎)和(高性能MySQL),前者对InnoDB的技术要点讲解的很深.后者则是流水账式的介绍MySQL的各个模块. 彼时笔者的背景知识极为有限:
所以两者都不适合.笔者需要的是这样的一本书
很幸运,笔者发现了< MySQL是怎么运行的 >,它达成了上述需求的90%.如果你跟笔者有类似的问题,那么读下这本书吧!
推荐大家重点阅读下面章节
从此跟乱码say goodbye
了解记录在内存中的结构,B+树的演变由来,以及为什么要使用索引–没有索引就要扫全表呀!
缓冲池提高了性能,也带来了问题.
做完的事情说什么也不能丢失.
第一次听说脏写和Read View.看完之后才知道事务隔离级别的实现差异.
祝大家有一个愉快的阅读体验~
mysql 5.7.28
按id增序 导出t_order_detail表数据，由于数据量过多，防止一次查询数据量大多导致异常，批量查询数据，每次查询200条数据，数据量50万，查询出的数据量5万多条。
SQL如下
Explain结果
《高性能MySql第三版》章节6.7.5 优化Limit分页中提到，在偏移量非常大的时候，例如可能是LIMIT 1000,20 这样的查询，这时候MySQL需要查询10020条记录然后只返回最后20条，前面10000条记录都将被抛弃，这样的代价非常高。要优化此种查询，要么在页面中限制分页数量，要么是优化大偏移量的性能。使用“延迟关联”，它让MySQL扫描尽可能少的页面，获取需要要访问的记录后再根据关联列回原表查询需要的所有列。
Explain结果
也没看不出来区别，直接用SQL执行看消耗的时间
这个延迟关联蛮简单的(自我感觉)，为啥MySQL不直接内部实现优化呢？
延迟关联到底节省了哪部分动作消耗的时间，如果只是如下的SQL,那就根本没必要关联，在查询了其他的字段后，才需要延迟关联。所以是节省了获取其他字段的消耗的时间？还是排序时多个字段后更加耗时？
当前SQL使用id排序，可以直接使用上一页数据最后一条数据的Id做筛选，这样直接筛选出需要的数据，查询查第49999条数据的order_id为707352，SQL如下
Explain结果
此种优化方法要求 使用唯一的字段排序。
高性能MySql
MySQL ORDER BY _ LIMIT performance_ late row lookups at EXPLAIN EXTENDED
以上就是关于MySQL高性能SQL注意事项简述全部的内容，如果了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！
