1. 先对表和SQL有个基本理解，再开始写SQL代码

虽说学习编程最好是边看边练，但由于SQL（面向集合的说明式语言）与常见的过程式编程语言在思维上有明显不同，所以学习SQL的一开始，最好先对表和SQL的查询有个基本理解（可参看本站如何学习SQL，特别是第二部分），再开始写SQL代码。

如果没有基本理解就直接东拼西凑硬写代码：
1) 很容易把表理解成一个二维数组，从而习惯性地写出低效的循环处理，还会觉得为什么这个“数组”这么难用，连下标访问都不能。（提示：表是记录的集合）。
2) 一般的过程式编程语言，只要语法能通过，逻辑上问题一般不会太大；而写出语法上能通过的SQL语句，逻辑却可能差之毫厘谬之千里。（比如少写一个条件导致笛卡尔积）。盲人摸象式的学SQL，很容易被SQL各种“零散”的语法特性迷惑，觉得SQL好难学啊，而只要从关系的角度理解表，SQL简直就像说话一样简单。
3) 一般的过程式编程语言，出错了最多程序crash掉，终止调试、修改代码、重新运行即可；而SQL操作的都是数据库里的持久层数据，一个操作不当的错误运行，就可能导致数据破坏、数据丢失等灾难性后果。（提示：良好的SQL编码习惯，权限合理分配，勤做备份）。

2. 关于动态SQL、触发器、游标

这几种是DBMS为了满足某些特定需求而提供的功能。使用这些功能要付出难调试、难维护、低性能的代价。

千万不要因为它们看起来复杂就觉得很高深，更不要因为觉得使用这些复杂功能看起来很牛，就让它们在代码中频频出现。这些功能应该掌握，但要尽量避免使用。如果数据库设计合理，这些东西基本是可以避免使用的。

武侠片中有个规律：使用的武器越是复杂、神秘、骇人的角色，其武功越是一般。而绝顶高手往往一把片刀、一把扫帚甚至赤手空拳就能威震江湖。记住IT领域的KISS原则，简单的往往是最好的，正是此理。

3. 不要过早优化

Knuth有句名言：“过早优化是万恶之源”（有兴趣可参看《Unix编程艺术》1.6.15节）。在SQL中支持这一观点的理由如下：
1) 新手常常会低估DBMS的处理能力，或者高估实际问题的规模（数据量）。
2) 即使需要优化，也要遵循科学的优化方法（简单来说是：建立基线、寻找瓶颈、优化、测试）。盲目优化效果往往适得其反，既增加系统复杂度又降低效率。

当然，在数据库设计和编码时，一些高性能的架构设计和编码习惯是需要的。但这需要对数据库查询优化技术有深入了解。学习SQL总要一步一步来。

4. 不要人云亦云，盲目相信一些传闻

SQL查询优化是个复杂问题，硬件配置、DBMS版本、表结构定义、索引、数据量、查询语句，都会影响查询性能。判断一个语句的性能，最好是自己尝试一下，观察执行计划和统计数据。而对于网上看到的论断，即使不能一一尝试，至少也要想一下为什么，而不是盲目相信。

在CSDN论坛上看到的流传甚广的传闻：
1) WHERE CHARINDEX('abc', ColumnName)  > 0 比 WHERE ColumnName LIKE '%abc%' 性能好。
2) 用JOIN判断A表数据在/不在B表比 IN/NOT IN 和 EXISTS/NOT EXISTS 性能好。
很好奇这些传闻是怎么产生的。