为何在sql查询中必要利用xxx is null而不克不及利用xxx=null详解
CSV逻辑上由逗号分割数据的存储引擎应当人人都很分明，我们在sql中要查询某列值为null的一切了局集时，查询前提应当如许写select*from表where字段isnull
而利用select*from表where字段=null是查不到准确的了局的。那这是为何呢？要分明为何，就必要懂得sql中的三值逻辑了。
在SQL中逻辑表达式的大概值包含TRUE、FALSE和UNKNOWN，它们被称之为三值逻辑。
我们晓得，在别的的言语中，逻辑表达式只要两种，要末是true,要末就是false。而sql中却存在第三个逻辑表达式UnKnown，这个是sql中独有的。从字面意义上我们能够解理该值的意义是：甚么都不晓得，就是甚么都不是。一样平常情形下我们将任何值(包含NULL自己)与NULL做对照的时分，城市前往UnKnown。而在查询表达式中(好比where与having中)，UnKnown会视为false。以是我们就分明了为何select*from表where字段=null查不到准确的了局的缘故原由了。
但并非在一切场情下UnKnown城市视为false来处置，在check束缚中，UnKnown就会视为true来处置。这就是为何我们设置某个字段的值必需年夜于即是0的情形下，我们还能够往该字段中拔出Null值，那是由于在check束缚中null>=0的逻辑了局UnKnown会被看成true来处置。
必要注重的是，在分组子句与排序子句中，sql视null是相称的
即：
1，GROUPBY会把一切NULL值分到一组。
2，ORDERBY会把一切NULL值分列在一同。限制,如果WHERE子句的查询条件里有不等号（WHEREcoloum!=），MySQL将无法使用索引。类似地，如果WHERE子句的查询条件里使用了函数（WHEREDAY（column）=），MySQL也将无法使用索引。 原来的计算字段其实和虚拟字段很像。只是管理方面好了而已，性能方面提高不多。但是SQL2005提供了计算字段的持久化，这就提高了查询的性能，但是会加重insert和update的负担。OLTP慎用。OLAP可以大规模使用。 很多书籍啊，不过个人认为看书太慢，还不如自己学。多做实际的东西，就会遇到很多问题，网上搜下解决问题。不断重复这个过程，在配合sql的F1功能。 分区表是个亮点！从分区表也能看出微软要做大作强SQLServer的信心。资料很多，这里不详细说。但是重点了解的是：现在的SQLServer2005的表，都是默认为分区表的。因为它要支持滑动窗口的这个特性。这种特性对历史数据和实时数据的处理是很有帮助的。 多走走一此相关论坛，多看一些实例开发，多交流0经验，没什么的，我也是刚学没多久!加油 可能有的朋友会抱怨集成的orderby，其实如果使用ranking函数,Orderby是少不了的。如果担心Orderby会影响效率，可以为orderby的字段建立聚集索引，查询计划会忽略orderby操作（因为本来就是排序的嘛）。 groupby子句可以将查询结果分组，并返回行的汇总信息Oracle按照groupby子句中指定的表达式的值分组查询结果。 发几份SQL课件，以飨阅者 连做梦都在想页面结构是怎么样的，绝非虚言
页:
[1]