本来还想来个分类分级的。算了，先罗列出来。以后攒得更多了，再考虑。赶时间，先随便写。 bads - 不写表注释。字段含义全靠猜字段英文名字，或者去问业务系统研发。 - 不写代码注释。反正可以读代码读懂的，主打一个代码 self-documenting。 - 不写具备 self-documenting 的代码。（我其实不知道这个词的具体含义，但是我就用了）<- is this some kind of not self-documenting? - 不缩进，或者随意缩进。缩一个七荤八素，让子查询关键词和外层的对齐，同时子查询爱对齐不对齐。我也不知道在说什么，正如我看不懂这段sql写的是什么。 - 括号不对齐。前端开发可爱对齐括号了，但是咱们写sql的无所谓，有编辑器的五彩斑斓的括号颜色，看得你眼珠子五彩斑斓。 - 不写清楚 join 的条件，多多使用 natural join，主打一个 join 的莫名其妙。 - 多表关联后，不写表缩写，反正同名字段是必须写表缩写的。但是不写表缩写的字段，用着用着就不知道这个 start_time 是谁的 start_time 了（随意举个例子）。 - 能一次做完的逻辑，要拆开在不同的位置实现。配合下面这些操作，体验更加爽利： - 能在一次 join 后拿到数据的，分 2 次。先 join 一次拿到一部分字段处理 A 部分逻辑，到几层外的查询里再 join 一次，获得另外几个字段处理 B 部分的逻辑。于此同时，两个 join 里的加点“调味代码”。 - 同一个计算，有多种实现方式的，在不同的位置采用不同的实现方式。 - 在某一个 join 里同时处理另外一个不想干的逻辑，显得这个 join 和 那个 join 的的逻辑差异是如此之不同，不得不分开处理。 - 不喜欢 join 太多，可以这一次使用 with 语句，但是不把上一次的 join 语句删掉。这样，你的代码里会多出一个小尾巴一样短短的表名，但是它的本地距离此地还有300行代码。 - 不同sql方言间偶尔会兼容一些公式，一定要用起来！这样处理日期的公式有 2 种，处理字符的公式有 3 种，让不熟悉那个方言的其他人一起学会把。 - 不使用维度表处理常用维，每次需要使用的时候，再写一遍！除非你的同事把你的代码抠出来单独运行一下，不然哪里可能知道你写的效果是什么？什么函数，什么单元测试，这在 sql 里不存在的嘛。抠出来，自己研究一下这段代码的 corner-case 处理逻辑。 - 能 if else 做的单字段判断，也可以用几个多胞胎的一样的 sql union 在一起嘛，大家的 where 语句不一样，大家都是亲戚哈。 goods - 因为业务数据是 prone-to-error 的，所以写 SQL 定义指标计算公式的时候，必须提前预判到业务数据记录的变动造成的公式失效或者漂移，这样的指标更健壮。转念一想，正常的 CRUD 不也是要干这事嘛。健壮的指标，总是要把新的情况排除在外，宁少勿错，少算几条记录也没事，总比多算入一些错误的记录要好；松弛的指标，经常允许意外记录纳入统计，一个也不放过。健壮的指标阻挡了问题，也遮盖了问题，应当配备异常log，来捕捉问题。松弛的指标，不遮盖问题，直接把问题怼脸上，让看数据的人遭受惊吓。你更喜欢哪一种？我喜欢健壮的，但是业务总是喜欢松弛的，然后在出错的时候 blame the sql gurl(guy-girl)。 （未完待续，想到再补...）