"两个datetime 列的不同招致了运转时溢出"的办理办法

MySQL这个名字是怎么来的已经不清楚了。基本指南和大量的库和工具带有前缀“my”已经有10年以上，而且不管怎样，MySQLAB创始人之一的的女儿也叫My。明天在SqlServer中查询一段工夫内的纪录时，sql报出了以下毛病：
两个datetime列的不同招致了运转时溢出。

测试后发明产生该成绩的次要缘故原由是由于两个datetime范例列盘算的了局值超越了却果的数据范例的最年夜值大概最小值，最有大概就是在sql中利用了datediff函数了。

datediff前往的了局是int范例，也就是它的取值局限从–2^31(-2,147,483,648)到2^31–1(2,147,483,647)。假如我们盘算的了局超越这个局限，就会报以上的毛病了。

我们来做个测试，在datediff函数以s为单元来做示例,先盘算一下超值局限，假如我们以秒为单元，那末盘算的工夫值只能在2,147,483,648/60/60/24/365=68年之间，假如超越68年，就会报错了。

测试：
selectdatediff(s,1900-1-1,1968-1-1)

两个日期相差68年，不会报错，实行前往了局2145830400。

selectdatediff(s,1900-1-1,1969-1-1)

两个日期相差69年，实行后前往毛病：两个datetime列的不同招致了运转时溢出。

总结：假如我们在做工夫对照的时分不断定两个工夫差的局限，就不要用datediff函数了，一不当心就报错了。这里我们讨论用binlog来实现闪回的方案。

再开发调试阶段和OLAP环境中，外键是可以建立的。新版本中加入了SETNULL和SETDEFAULT属性，能够提供能好的级联设置。

同样会为索引视图等应用带来麻烦。看看行级和事务级的快照数据放在tempdb中，就能感觉到目前架构的尴尬。

现在是在考虑:如果写到服务器端,我一下搞他个10个存储过程导过去,那久之服务器不就成垃圾箱了吗?即便优化了我的中间层.

你觉得我的非分区索引无法对起子分区，你可以提醒我一下呀！没有任何的提醒，直接就变成了非分区表。不知道这算不算一个bug。大家也可以试试。

如果我们从集合论（关系代数）的角度来看，一张数据库的表就是一组数据元的关系，而每个SQL语句会改变一种或数种关系，从而产生出新的数据元的关系（即产生新的表）。

微软对CLR作了大篇幅的宣传，这是因为数据库产品终于融入.net体系中。最开始我们也是狂喜，感觉对象数据库的一些概念可以实现了。

这就引发了对varchar和char效率讨论的老问题。到底如何分配varchar的数据，是否会出现大规模的碎片？