Sql建表和sql语句的注意事项

建表注意事项:
对于建表大家都不陌生,这里主要说明一下几点注意实现:
1、大数据字段最好剥离出单独的表,以便影响性能
2、使用varchar,代替char,这是因为varchar会动态分配长度,char指定为20,即时你存储字符“1”,它依然是20的长度 
3、给表建立主键,看到好多表没主键,这在查询和索引定义上将有一定的影响
4、避免表字段运行为null,如果不知道添加什么值,建议设置默认值,特别int类型,比如默认值为0,在索引查询上,效率立显。
5、建立索引,聚集索引则意味着数据的物理存储顺序,最好在唯一的,非空的字段上建立,其它索引也不是越多越好,索引在查询上优势显著,在频繁更新数据的字段上建立聚集索引,后果很严重,插入更新相当忙。
6、组合索引和单索引的建立,要考虑查询实际和具体模式.
SQL语句注意事项:
熟悉SQL的人,都会写SQL语句,但到底效率如何,十万以下的数据量,根本没任何区别,但一些基础性的东西,还是得点滴做起
1、where语句的书写,当有多个查询条件时,sql是按照从右往左的顺序进行执行,也就是说写在最后的条件会最早被执行,这就意味着过滤数据量最多的
添加应该写在最后,这样才能在性能上达到最优
2、join语句,如果A表1000w,B表30条记录,则应该是A join B,sql执行会以B为准去关联A,性能显著
3、表变量和临时表 ,这个问题可能有些同学稍陌生,所谓表变量就是declare @dd  table类似这样的声明,而临时表多见#tt,这样的格式这二者在sql内是区别对待的表变量功能有限,使用完自动释放,临时表计划就是有数据表的大部分功能,使用完毕后需要删除,在数据库tempdb也有对应的操作记录,使用时应该综合考虑。
4、注意聚合函数,is null,<>等的使用,当我们在这样使用的时候,可能习以为常,在大数据量处理上,本有的索引将不再被使用,而变成全表扫描,So ga等吧,性能大大的慢,如where  len(studentId)=0,本来在studentid上的索引变成全表扫描了。
5、使用exist代替not in,这个大家都知道,但还是希望大家注意下
6、select AA,BB,代替Select * ,这是大部分程序员的通病,总觉得无所谓,其实select * 在sql执行时还是要遍历到具体的字段名进行读取,即使我们要使用全部列,也推荐使用把各个字段都罗列处理,而非使用*
7、top n 和order by 你了解多少?我一直觉得where条件查询完后order by在此基础上进行排序,其实错了,在有top n和order by一块使用时,order by竟然是全表扫描,具体可以通过查询计划验证。
8、编码过程和单元测试过程尽量用数据量较大的数据库测试,最好能用实际数据测试
9、不要频繁更新有触发器的表的数据
其他注意事项:

1.合理使用索引

  索引是数据库中重要的数据结构,它的根本目的就是为了提高查询效率。现在大多数的数据库产品都采用IBM最先提出的ISAM索引结构。索引的使用要恰到好处,其使用原则如下:

  ●在经常进行连接,但是没有指定为外键的列上建立索引,而不经常连接的字段则由优化器自动生成索引。

  ●在频繁进行排序或分组(即进行group by或order by操作)的列上建立索引。

  ●在条件表达式中经常用到的不同值较多的列上建立检索,在不同值少的列上不要建立索引。比如在雇员表的“性别”列上只有“男”与“女”两个不同值,因此就无必要建立索引。如果建立索引不但不会提高查询效率,反而会严重降低更新速度。

  ●如果待排序的列有多个,可以在这些列上建立复合索引(compound index)。

  ●使用系统工具。如Informix数据库有一个tbcheck工具,可以在可疑的索引上进行检查。在一些数据库服务器上,索引可能失效或者因为频繁操作而使得读取效率降低,如果一个使用索引的查询不明不白地慢下来,可以试着用tbcheck工具检查索引的完整性,必要时进行修复。另外,当数据库表更新大量数据后,删除并重建索引可以提高查询速度。

  2.避免或简化排序

  应当简化或避免对大型表进行重复的排序。当能够利用索引自动以适当的次序产生输出时,优化器就避免了排序的步骤。以下是一些影响因素:

  ●索引中不包括一个或几个待排序的列;

  ●group by或order by子句中列的次序与索引的次序不一样;

  ●排序的列来自不同的表。

  为了避免不必要的排序,就要正确地增建索引,合理地合并数据库表(尽管有时可能影响表的规范化,但相对于效率的提高是值得的)。如果排序不可避免,那么应当试图简化它,如缩小排序的列的范围等。

  3.消除对大型表行数据的顺序存取

  在嵌套查询中,对表的顺序存取对查询效率可能产生致命的影响。比如采用顺序存取策略,一个嵌套3层的查询,如果每层都查询1000行,那么这个查询就要查询10亿行数据。避免这种情况的主要方法就是对连接的列进行索引。例如,两个表:学生表(学号、姓名、年龄……)和选课表(学号、课程号、成绩)。如果两个表要做连接,就要在“学号”这个连接字段上建立索引。

  还可以使用并集来避免顺序存取。尽管在所有的检查列上都有索引,但某些形式的where子句强迫优化器使用顺序存取。下面的查询将强迫对orders表执行顺序操作:

SELECT * FROM orders WHERE (customer_num=104 AND order_num>1001) OR order_num=1008

  虽然在customer_num和order_num上建有索引,但是在上面的语句中优化器还是使用顺序存取路径扫描整个表。因为这个语句要检索的是分离的行的集合,所以应该改为如下语句:

SELECT * FROM orders WHERE customer_num=104 AND order_num>1001 UNION SELECT * FROM orders WHERE order_num=1008

  这样就能利用索引路径处理查询。

  4.避免相关子查询

  一个列的标签同时在主查询和where子句中的查询中出现,那么很可能当主查询中的列值改变之后,子查询必须重新查询一次。查询嵌套层次越多,效率越低,因此应当尽量避免子查询。如果子查询不可避免,那么要在子查询中过滤掉尽可能多的行。

  5.避免困难的正规表达式

  MATCHES和LIKE关键字支持通配符匹配,技术上叫正规表达式。但这种匹配特别耗费时间。例如:SELECT * FROM customer WHERE zipcode LIKE “98_ _ _”

  即使在zipcode字段上建立了索引,在这种情况下也还是采用顺序扫描的方式。如果把语句改为SELECT * FROM customer WHERE zipcode >“98000”,在执行查询时就会利用索引来查询,显然会大大提高速度。

  另外,还要避免非开始的子串。例如语句:SELECT * FROM customer WHERE zipcode[2,3] >“80”,在where子句中采用了非开始子串,因而这个语句也不会使用索引。

  6.使用临时表加速查询

  把表的一个子集进行排序并创建临时表,有时能加速查询。它有助于避免多重排序操作,而且在其他方面还能简化优化器的工作。例如:

SELECT cust.name,rcvbles.balance,……other columns FROM cust,rcvbles WHERE cust.customer_id = rcvlbes.customer_id AND rcvblls.balance>0 AND cust.postcode>“98000” ORDER BY cust.name

  如果这个查询要被执行多次而不止一次,可以把所有未付款的客户找出来放在一个临时文件中,并按客户的名字进行排序:

SELECT cust.name,rcvbles.balance,……other columns FROM cust,rcvbles WHERE cust.customer_id = rcvlbes.customer_id AND rcvblls.balance>0 ORDER BY cust.name INTO TEMP cust_with_balance

  然后以下面的方式在临时表中查询:

SELECT * FROM cust_with_balance WHERE postcode>“98000”

  临时表中的行要比主表中的行少,而且物理顺序就是所要求的顺序,减少了磁盘I/O,所以查询工作量可以得到大幅减少。

  注意:临时表创建后不会反映主表的修改。在主表中数据频繁修改的情况下,注意不要丢失数据。

  7.用排序来取代非顺序存取

  非顺序磁盘存取是最慢的操作,表现在磁盘存取臂的来回移动。SQL语句隐藏了这一情况,使得我们在写应用程序时很容易写出要求存取大量非顺序页的查询。

  有些时候,用数据库的排序能力来替代非顺序的存取能改进查询。

总结:

  可见,所谓优化即where子句利用了索引,不可优化即发生了表扫描或额外开销。

  1.任何对列的操作都将导致表扫描,它包括数据库函数、计算表达式等等,查询时要尽可能将操作移至等号右边。

  2.in、or子句常会使用工作表,使索引失效;如果不产生大量重复值,可以考虑把子句拆开;拆开的子句中应该包含索引。

  3.要善于使用存储过程,它使SQL变得更加灵活和高效

本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。
原文地址:https://www.cnblogs.com/newstart/p/2549690.html