写SQL怎么写得快又稳，这些经验你可能没全掌握但挺管用

写SQL要想又快又稳，没啥高深莫测的秘诀，就是一些很实在的经验和习惯，这些东西可能没人系统教过你，但用好了效果立竿见影，下面这些点，有些你可能知道但没坚持，有些可能真没留意过,都来自一线工程师的长期实践。

第一，动手之前先想清楚，别急着敲键盘。 这是最容易被忽略也最重要的一点，很多人接到需求，脑子里大概有个模糊的方向就开始噼里啪啦写SELECT，结果写了一半发现关联表不对，或者条件逻辑有漏洞，又得删掉重来，正确的做法是，先用大白话或者笔画一画：我最终要得到什么样的数据？需要用到哪几张表？这几张表靠什么字段关联起来？过滤条件是什么？有没有分组和排序的要求？这个过程花不了几分钟，但能帮你把整个逻辑理顺，避免写到一半卡壳，反而节省了大量时间，这就好比出门前先想好路线,总比开到半路再频繁调头要快得多。

第二，养成先写SELECT子句的习惯，但最后再完善它。 这是个非常实用的小技巧，一开始，你可以在SELECT后面只放一个星号（*），或者只放一两个核心字段，然后快速地把FROM、JOIN、WHERE这些主要的子句搭建起来，为什么要这样？因为你的首要任务是确保数据关联和过滤的基础框架是正确的，你先用LIMIT 10（或者TOP 10，取决于你的数据库）跑一下，看看出来的几条数据是不是你预期的那样，关联关系对不对，等这个大框架验证没问题了，你再返回到SELECT子句，把真正需要的字段一个个明确列出来，替换掉星号，这样做有两个好处：一是调试起来快，二是最终避免了查询出不需要的字段,提升效率。

第三，多用WITH语句（也就是公用表表达式CTE）把复杂查询拆解开。 如果你的SQL语句特别长，嵌套了很多层，或者一段逻辑被反复使用，那一定要学会用WITH，它的作用就是把一段复杂的查询临时保存成一个类似虚拟表的东西，然后你可以在主查询里像用普通表一样去引用它，这相当于把一个大任务拆成了几个步骤清晰的小任务，你可以先把一个复杂的过滤条件用WITH定义成一个临时表A，再把另一个统计结果定义成临时表B，最后主查询就只需要清晰地写A和B怎么关联，这样做，SQL的可读性会大大增强，过几个月你回来看，或者别人来维护，都能很快看懂，调试也方便，你可以单独运行每一个WITH模块，检查中间结果对不对，而不是对着一个上百行的庞大查询干瞪眼,这个经验在处理多层子查询时尤其管用。

第四，条件筛选时，时刻注意NULL值这个“陷阱”。 很多查询结果出问题，根源都在NULL值上，你写 WHERE column_name != '某个值'，如果这个column_name字段存在NULL值，那么这些NULL记录是不会出现在结果里的，因为NULL代表未知，数据库不会认为它等于或不等于任何一个具体的值，如果你的业务逻辑需要考虑到NULL的情况，一定要显式地加上判断，WHERE (column_name != '某个值' OR column_name IS NULL)，类似的，在LEFT JOIN（左连接）时，如果想筛选右表的字段，也要小心，直接写在WHERE条件里，可能会让左连接意外地变成内连接的效果，这时候，把针对右表的筛选条件放到ON子句里往往是更稳妥的做法，多留个心眼,能避免很多诡异的数据丢失问题。

第五，写完SQL一定要用少量数据验证一下。 不要写完就直接扔去跑生产环境的大表，先用LIMIT限制返回几条结果，或者找一个有代表性的小数据样本，人工核对一下这几条结果是否正确，重点检查：数据关联对了没有？有没有重复数据？计算字段的值算得对不对？排序是否符合预期？这个简单的步骤是“稳”的关键，能帮你拦截掉大部分的低级错误，有时候你觉得自己逻辑天衣无缝，但一查数据才发现某个关联键不是一对一的关系，导致了数据重复,这种问题在少量数据上一目了然。

第六，关注查询性能，从习惯做起。 虽然性能优化是门大学问，但有些好习惯平时就能养成，最基本的一条：尽量不用SELECT *，你需要哪些字段就明确写出来，特别是当表字段非常多或者有大型文本字段时，这能显著减少网络传输和数据处理的负担，如果某个查询是经常要跑的，可以看看能不能给它加一个合适的索引，尤其是用在WHERE条件、JOIN关联键和ORDER BY排序上的字段，加索引要谨慎，会影响写数据的性能,但对于读多写少的场景效果很好。

第七，把常用的查询片段保存下来。 工作中你会发现，有些查询逻辑是会反复用到的，比如按时间范围筛选、某种特定的状态转换逻辑、或者一个复杂的计算公式，不要每次都重新写一遍，很容易出错，你可以把这些“代码块”保存在一个文本文件里，或者数据库的保存查询（如果有这功能）中，甚至只是记在一个文档里，下次需要用的时候，直接复制粘贴再稍作修改，又快又不容易出错,这相当于给你自己建了一个小工具箱。

也是很重要的一点，多进行代码复查，写完SQL后，如果条件允许，找个同事帮你简单看一眼，或者哪怕是自己，放一放，过半个小时再以 fresh eyes（新鲜的视角）重新审视一遍，经常能发现一些自己当时陷进去看不到的明显逻辑错误或者笔误，俗话说，旁观者清,这在写SQL时也一样适用。

写SQL又快又稳，核心就是“多想一步、多试一步、多总结一步”，这些经验谈不上多高级，但坚持下来，一定能让你少加很多班,少背很多锅。