技巧：
1. 索引并不是越多越好
2.对查询进行优化，要尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。
提倡：
1. 在 where 及 order by 涉及的列上建立索引
eg: select * from tb_a => select * from tb_a where age=5 order by name
结论
查询速度提高了些,现在数据量还不明显,如果表中有10万条速度,差异就会很明显了.
2. 尽量使用数字型字段
原因：若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销。这是因为引擎在处理查询和连接时会逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。
3.尽可能的使用 varchar/nvarchar 代替 char/nchar
原因：首先变长字段存储空间小，可以节省存储空间，其次对于查询来说，在一个相对较小的字段内搜索效率显然要高些。
4.很多时候用 exists 代替 in 、DISTINCT是一个好的选择
5.用UNION替换OR (适用于索引列)
6 使用连接（JOIN）来代替子查询(Sub-Queries)
6.利用表分区
分区将数据在物理上分隔开，不同分区的数据可以制定保存在处于不同磁盘上的数据文件里。这样，当对这个表进行查询时，只需要在表分区中进行扫描，而不必进行全表扫描，明显缩短了查询时间，另外处于不同磁盘的分区也将对这个表的数据传输分散在不同的磁盘I/O，一个精心设置的分区可以将数据传输对磁盘I/O竞争均匀地分散开。对数据量大的时时表可采取此方法。可按月自动建表分区。
7.调整硬盘I/O
这一步是在信息系统开发之前完成的。数据库管理员可以将组成同一个表空间的数据文件放在不同的硬盘上，做到硬盘之间I/O负载均衡。在磁盘比较富裕的情况下还应该遵循以下原则：
将表和索引分开；
创造用户表空间，与系统表空间（system）分开磁盘；
创建表和索引时指定不同的表空间；
创建回滚段专用的表空间，防止空间竞争影响事务的完成；
创建临时表空间用于排序操作，尽可能的防止数据库碎片存在于多个表空间中。
避免：
1.减少where 字段值null判断
原因：这样做,就会导致引擎放弃使用索引而进行全表扫描
应该：这样去设置(也就是在没有值时,我们在存数据库时自动默认给个o值,而不是什么都不写):
2.尽量避免向客户端返回大数据量
若数据量过大，应该考虑相应需求是否合理
3 应尽量避免在 where 子句中使用!=或<>操作符
原因：将导致引擎放弃使用索引而进行全表扫描
4. in 和 not in 也要慎用
原因：这样操作,也会导致全表扫描
应该：以通配符*去查询所有数据,这样做也是非常耗时的,我们应该需要什么字段就查询什么字段
5. 不要在条件判断时进行 算数运算
原因：不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算,这样系统将可能无法正确使用索引
6.很多时候用 exists 代替 in 、DISTINCT是一个好的选择
7.一般情况下不鼓励使用like操作
