一个奇怪的SQL问题

今天在进行SQL审核的时候，遇到了一个奇怪的SQL，SQL如下：

create table datatype10

(d_tinyint int not null default 1 comment "a",

d_smallint int not null default 1 comment 'a',

d_timestart timestamp default '1970-01-01 08:00:03' not null ,

d_timestop timestamp default '2038-01-19 11:14:06' not null ,

d_enum enum('man','woman')

);

该SQL在执行的时候，报三个警告，本机版本是5.7.16的MySQL数据库，当时不理解，打开warnings看看到底是什么原因：

很明显，提示timestamp时间类型的值不对，需要修改时间值，于是查阅Timestamp类型的正确范围，得到结果是：1970-01-01 00:00:01到2038-01-19 03:14:07 ，再通过地理位置计算得知我们需要的正确时间值是：1970-01-01 08:00:01到2038-01-19 11:14:07

看了看自己输入的时间值，是在范围内的，那么为什么会出现这个结果呢？于是将这个SQL通过拷贝的方式给同事看看，同事拿到SQL在他那边跑了一下，输出的结果如下:

create table datatype10

(d_tinyint int not null default 1 comment "a",

d_smallint int not null default 1 comment 'a',

d_timestart timestamp default '1970-01-01 08:00:03' not null ,

d_timestop timestamp default '2038-01-19 11:14:06' not null ,

d_enum enum('man','woman')

);

直接通过了，我去，难道SQL语句也看人品么，我不服，重新尝试了自己的SQL，还是一直报错：

同事坐在我的电脑旁边进行操作，拷贝了我俩聊天记录里面的我给他的SQL，在我的电脑上显示的结果：

what a pity！！！我去，还真是，看人品啊，人家跑就可以，我自己跑就报警告，为什么呢，当时很不理解这个问题，但是读者们看到这里，可能心里已经有了答案，那就是我给同事的SQL和我自己跑的那个SQL肯定不是一样的！！！

于是，重新将两个SQL跑了下，进行了对比，结果如下：

果然是这样的，到底是什么原因导致这种问题呢，肯定是两者的内容有不一样的地方，于是将两个SQL语句放在一个文件里面，利用：

cat -v 文件名

命令，查看文件中的隐藏字符，结果如下：

原来如此！！！看到这里，可能恍然大悟了，原来是文字在拷贝的过程中发生了变化，我的SQL本身存在”M-BM-”的字符在里面，复制粘贴给同事之后，这个东西就莫名其妙的消失了，也就是说，通过拷贝，把我错误的SQL字符给自动修正了，所以他的就可以跑，我的就不能跑！！！

一个小小的问题，疑惑和很久，于是想着，既然有问题，就直接把这个奇怪的字符换成一个可见的字符处理一把，看看结果有什么差异，于是有了下面的SQL：

create table datatype10

(d_tinyint int not null default 1 comment "a",

d_smallint int not null default 1 comment 'a',

d_timestart timestamp default '1970-01-01 08:00:03' not null ,

d_timestop timestamp default '2038-01-19 11:14:06' not null ,

d_enum enum('man','woman')

);

//注意，这里给timestamp类型中间添加了可见的字符a

create table datatype10

(d_tinyint int not null default 1 comment "a",

d_smallint int not null default 1 comment 'a',

d_timestart timestamp default '1970-01-01a08:00:03' not null ,

d_timestop timestamp default '2038-01-19a11:14:06' not null ,

d_enum enum('man','woman')

);

结果如下：

到这里，问题已经和明确了，确实是因为两个SQL不一样导致的，我的SQL可能因为中英文切换的原因，夹杂进来一个不需要的字符，导致整个SQL报警告，但是也证明了一点，timestamp不会对这种警告进行处理，只会通过警告的方式告诉DBA，这个数据可能有问题，这个表还是被创建成功了。

所以以后遇到这种问题，尽量还是保持字符的统一，不要来回切换中英文，保证文本编辑器都在统一系统的utf-8编码格式下进行。

虽然问题很小，但是还算有所收获，就分享出来，大家高兴高兴！！！