mysql数据库 表中的字段类型 为什么会无缘无故的自动改变呢？

mysql数据库 表中的字段类型 为什么会自动改变？ 
 

本来我创建的数据库的表中的字段是char类型的 

但是当用了一段时间以后 

再打开数据库看看 就变成了int类型的啦


怎么回事啊 谁能告诉我解决方法？

9 个解决方案

#1

也许你记错了。。。

#2

我也是这么想的 但是 当我看到它是int类型的时候 我把它改成char型的啦 谁知道用了一段时间 当我打开数据库看的时候它就又无缘无故的变成了 int类型的啦  真的好郁闷 不知道怎么回事 有谁遇到过这种情况吗 怎么解决的？

#3

我很好奇 灰常 好奇，太经典的错误了。第一次呀

#4

开启binlog，这样更新就会记录。然后在里面搜ALTER TABLE 你的表名 即可。

#5

没有这种可能，一定是某个程序，或者某个人进行了这种ALTER TABLE的操作。

打开你的日志，然后从日志中检查一下。

#6

真的很奇怪 以前一直用着也没这种情况 就最近一周总是这样 很郁闷 应该是没有人修改我的表啊 请问日志在哪里有可以查到呢？

#7

MySQL 5.1参考手册

5.11. MySQL日志文件
5.11.1. 错误日志
5.11.2. 通用查询日志
5.11.3. 二进制日志
5.11.4. 慢速查询日志
5.11.5. 日志文件维护
MySQL有几个不同的日志文件，可以帮助你找出mysqld内部发生的事情：

日志文件
 记入文件中的信息类型
 
错误日志
 记录启动、运行或停止mysqld时出现的问题。
 
查询日志
 记录建立的客户端连接和执行的语句。
 
更新日志
 记录更改数据的语句。不赞成使用该日志。
 
二进制日志
 记录所有更改数据的语句。还用于复制。
 
慢日志
 记录所有执行时间超过long_query_time秒的所有查询或不使用索引的查询。
 

默认情况下，所有日志创建于mysqld数据目录中。通过刷新日志，你可以强制 mysqld来关闭和重新打开日志文件（或者在某些情况下切换到一个新的日志）。当你执行一个FLUSH LOGS语句或执行mysqladmin flush-logs或mysqladmin refresh时，出现日志刷新。参见13.5.5.2节，“FLUSH语法”。

如果你正使用MySQL复制功能，从复制服务器将维护更多日志文件，被称为接替日志。相关讨论参见第6章：MySQL中的复制。

5.11.1. 错误日志
错误日志文件包含了当mysqld启动和停止时，以及服务器在运行过程中发生任何严重错误时的相关信息。

如果mysqld莫名其妙地死掉并且mysqld_safe需要重新启动它，mysqld_safe在错误日志中写入一条restarted mysqld消息。如果mysqld注意到需要自动检查或着修复一个表，则错误日志中写入一条消息。

在一些操作系统中，如果mysqld死掉，错误日志包含堆栈跟踪信息。跟踪信息可以用来确定mysqld死掉的地方。参见E.1.4节，“使用堆栈跟踪”。

可以用--log-error[=file_name]选项来指定mysqld保存错误日志文件的位置。如果没有给定file_name值，mysqld使用错误日志名host_name.err 并在数据目录中写入日志文件。如果你执行FLUSH LOGS，错误日志用-old重新命名后缀并且mysqld创建一个新的空日志文件。(如果未给出--log-error选项，则不会重新命名）。

如果不指定--log-error，或者(在Windows中)如果你使用--console选项，错误被写入标准错误输出stderr。通常标准输出为你的终端。

在Windows中，如果未给出--console选项，错误输出总是写入.err文件。

5.11.2. 通用查询日志
如果你想要知道mysqld内部发生了什么，你应该用--log[=file_name]或-l [file_name]选项启动它。如果没有给定file_name的值， 默认名是host_name.log。所有连接和语句被记录到日志文件。当你怀疑在客户端发生了错误并想确切地知道该客户端发送给mysqld的语句时，该日志可能非常有用。
mysqld按照它接收的顺序记录语句到查询日志。这可能与执行的顺序不同。这与更新日志和二进制日志不同，它们在查询执行后，但是任何一个锁释放之前记录日志。(查询日志还包含所有语句，而二进制日志不包含只查询数据的语句）。 

服务器重新启动和日志刷新不会产生新的一般查询日志文件(尽管刷新关闭并重新打开一般查询日志文件)。在Unix中，你可以通过下面的命令重新命名文件并创建一个新文件：

shell> mv hostname.log hostname-old.log
shell> mysqladmin flush-logs
shell> cp hostname-old.log to-backup-directory
shell> rm hostname-old.log
在Windows中，服务器打开日志文件期间你不能重新命名日志文件。你必须先停止服务器然后重新命名日志文件。然后，重启服务器来创建新的日志文件。

5.11.3. 二进制日志
二进制日志以一种更有效的格式，并且是事务安全的方式包含更新日志中可用的所有信息。

二进制日志包含了所有更新了数据或者已经潜在更新了数据（例如，没有匹配任何行的一个DELETE）的所有语句。语句以“事件”的形式保存，它描述数据更改。

注释：二进制日志已经代替了老的更新日志，更新日志在MySQL 5.1中不再使用。

二进制日志还包含关于每个更新数据库的语句的执行时间信息。它不包含没有修改任何数据的语句。如果你想要记录所有语句（例如，为了识别有问题的查询），你应使用一般查询日志。参见5.11.2节，“通用查询日志”。

二进制日志的主要目的是在恢复使能够最大可能地更新数据库，因为二进制日志包含备份后进行的所有更新。

二进制日志还用于在主复制服务器上记录所有将发送给从服务器的语句。参见第6章：MySQL中的复制。

运行服务器时若启用二进制日志则性能大约慢1%。但是，二进制日志的好处，即用于恢复并允许设置复制超过了这个小小的性能损失。

当用--log-bin[=file_name]选项启动时，mysqld写入包含所有更新数据的SQL命令的日志文件。如果未给出file_name值， 默认名为-bin后面所跟的主机名。如果给出了文件名，但没有包含路径，则文件被写入数据目录。建议指定一个文件名，原因参见A.8.1节，“MySQL中的打开事宜”。

如果你在日志名中提供了扩展名(例如，--log-bin=file_name.extension)，则扩展名被悄悄除掉并忽略。

mysqld在每个二进制日志名后面添加一个数字扩展名。每次你启动服务器或刷新日志时该数字则增加。如果当前的日志大小达到max_binlog_size，还会自动创建新的二进制日志。如果你正使用大的事务，二进制日志还会超过max_binlog_size：事务全写入一个二进制日志中，绝对不要写入不同的二进制日志中。

为了能够知道还使用了哪个不同的二进制日志文件，mysqld还创建一个二进制日志索引文件，包含所有使用的二进制日志文件的文件名。默认情况下与二进制日志文件的文件名相同，扩展名为'.index'。你可以用--log-bin-index[=file_name]选项更改二进制日志索引文件的文件名。当mysqld在运行时，不应手动编辑该文件；如果这样做将会使mysqld变得混乱。

可以用RESET MASTER语句删除所有二进制日志文件，或用PURGE MASTER LOGS只删除部分二进制文件。参见13.5.5.5节，“RESET语法”和13.6.1节，“用于控制主服务器的SQL语句”。

二进制日志格式有一些已知限制，会影响从备份恢复。参见6.7节，“复制特性和已知问题”。

保存程序和触发器的二进制日志的描述参见20.4节，“存储子程序和触发程序的二进制日志功能”。

可以使用下面的mysqld选项来影响记录到二进制日志知的内容。又见选项后面的讨论。

·         --binlog-do-db=db_name

告诉主服务器，如果当前的数据库(即USE选定的数据库)是db_name，应将更新记录到二进制日志中。其它所有没有明显指定的数据库  被忽略。如果使用该选项，你应确保只对当前的数据库进行更新。

对于CREATE DATABASE、ALTER DATABASE和DROP DATABASE语句，有一个例外，即通过操作的数据库来决定是否应记录语句，而不是用当前的数据库。

一个不能按照期望执行的例子：如果用binlog-do-db=sales启动服务器，并且执行USE prices; UPDATE sales.january SET amount=amount+1000；，该语句不写入二进制日志。

·         --binlog-ignore-db=db_name

告诉主服务器，如果当前的数据库(即USE选定

#8

谢谢 我再找找看^_^  错误真是莫名其妙

#9

坑爹呀，我 的 数据值，自动恢复。 我同步成新的， 过会又自动还原成旧的，，， 无语了。不知道是那的问题，我的mysql 5.5.24 是 我换成 5.6.10了。 大爷的还是  自动还原呀