#青训营笔记创作活动#
1月23日 打卡day44
今日学习
今天的内容关于SQL语句。
面对一个较为复杂或较难实现的业务需求时,就可以按照需求进行逐步拆分,化繁为简后逐步实现。其实对于这个道理很多人都懂,但往往在实际编写SQL时却想着一步到位,这也是我接触很多程序员后发现的问题:经验尚未丰富的开发,面对一个需求时通常都想着从头写到尾。但这样写就很容易卡壳,对于简单的业务需求可以这样做,但面对复杂业务时一定要先拆解需求后再逐步实现。
一个查询条件会依赖于另一条SQL的执行结果来决定,很多人在这种情况下会直接组合起来一起写,但这会导致编写SQL的复杂度再次提升,因此在这种情况下,可以先用指定值作为条件去查询,例如xx = "xxx",后面等整体SQL完成后,再套入SQL。
每条SQL的执行效率也要可控。
查询时尽量不要使用*,会导致分析成本变高,网络开销变大,内存占用变高,维护性变差。
连表查询时尽量不要关联太多表。
多表查询时一定要以小驱大。
不要使用like左模糊和全模糊查询。
查询时尽量不要对字段做空值判断。
不要在条件查询=前对字段做任何运算。
!=、!<>、not in、not like、or...要慎用。
必要情况下可以强制指定索引。
避免频繁创建、销毁临时表。
尽量将大事务拆分为小事务执行。
从业务设计层面减少大量数据返回的情况。
尽量避免深分页的情况出现。
SQL务必要写完整,不要使用缩写法。
基于联合索引查询时请务必确保字段的顺序性。
客户端的一些操作可以批量化完成。
明确仅返回一条数据的语句可以使用limit 1。
客户端访问时,能够在1s内得到响应,用户会觉得系统响应很快,体验非常好。 客户端访问时,1~3秒内得到响应,处于可以接受的阶段,其体验感还算不错。 客户端访问时,需要等待3~5秒时才可响应,这是用户就感觉比较慢了,体验有点糟糕。 客户端访问时,一旦响应超过5秒,用户体验感特别糟糕,通常会选择离开或刷新重试。
改善SQL的写法,理解一些SQL导致索引失效的场景,以及撰写SQL时的一些技巧,就能写出一手优质SQL。
展开
评论