mysql 里 date的长度 为啥总是为0

Posted 2023-05-02

昨天没发现什么问题 今天sql总报错 一看日期都是0000-00-00 后来发现 日期字段我用的date类型的 长度不知道为什么变为0了 手动修改了字段长度 点保存后 它又变成0了 请问是怎么回事

我用的一个选择日期的控件 传过来的是2011-01-26 字符串 我把字段改成varchar类型 插入的数据是个2005 不明白 有人说改成int 然后把日期格式化 请问具体怎么做呢

那是因为你插入的数据不符合date数据类型的合法格式..
DATE:4字节 1000-01-01 ----9999-12-31

至于出现0000-00-00 那是mysql的处理机制，当你插入的数据格式不是规范的date类型要求的格式的时候，自动转化成0000-00-00这个值 ~

参考资料：http://blog.csdn.net/feixianxxx/archive/2010/05/14/5592870.aspx

参考技术A date长度就是0 跟你sql报错没关系。。。估计是你数据插入有问题。。。你见过0000-00-00 这种日期不？建议数据插入前检测数据格式 参考技术B 以每24小时作为一份时间（而非自然日），根据用户的配置有两种工作模式：带状模式中，用户仅定义开始日期时，从开始日期（含）开始，每份时间1个分片地无限增加下去；环状模式中，用户定义了开始日期和结束日期时，以结束日期（含）和开始日期（含）之间的时间份数作为分片总数（分片数量固定），以类似取模的方式路由到这些分片里。

1. DBLE 启动时，读取用户在 rule.xml 配置的 sBeginDate 来确定起始时间
2. 读取用户在 rule.xml 配置的 sPartionDay 来确定每个 MySQL 分片承载多少天内的数据
3. 读取用户在 rule.xml 配置的 dateFormat 来确定分片索引的日期格式
4. 在 DBLE 的运行过程中，用户访问使用这个算法的表时，WHERE 子句中的分片索引值（字符串），会被提取出来尝试转换成 Java 内部的时间类型
5. 然后求分片索引值与起始时间的差，除以 MySQL 分片承载的天数，确定所属分片

1. DBLE 启动时，读取用户在 rule.xml 配置的起始时间 sBeginDate、终止时间 sEndDate 和每个 MySQL 分片承载多少天数据 sPartionDay
2. 根据用户设置，建立起以 sBeginDate 开始，每 sPartionDay 天一个分片，直到 sEndDate 为止的一个环，把分片串联串联起来
3. 读取用户在 rule.xml 配置的 defaultNode
4. 在 DBLE 的运行过程中，用户访问使用这个算法的表时，WHERE 子句中的分片索引值（字符串），会被提取出来尝试转换成 Java 内部的日期类型
5. 然后求分片索引值与起始日期的差：如果分片索引值不早于 sBeginDate（哪怕晚于 sEndDate），就以 MySQL 分片承载的天数为模数，对分片索引值求模得到所属分片；如果分片索引值早于 sBeginDate，就会被放到 defaultNode 分片上

与MyCat的类似分片算法对比

中间件
DBLE
MyCat

分片算法种类 date 分区算法 按日期（天）分片
两种中间件的取模范围分片算法使用上无差别

开发注意点
【分片索引】1. 必须是字符串，而且 java.text.SimpleDateFormat 能基于用户指定的 dateFormat 来转换成 java.util.Date
【分片索引】2. 提供带状模式和环状模式两种模式
【分片索引】3. 带状模式以 sBeginDate（含）起，以 86400000 毫秒（24 小时整）为一份，每 sPartionDay 份为一个分片，理论上分片数量可以无限增长，但是出现 sBeginDate 之前的数据而且没有设定 defaultNode 的话，会路由失败（如果有 defaultNode，则路由至 defaultNode）
【分片索引】4. 环状模式以 86400000 毫秒（24 小时整）为一份，每 sPartionDay 份为一个分片，以 sBeginDate（含）到 sEndDate（含）的时间长度除以单个分片长度得到恒定的分片数量，但是出现 sBeginDate 之前的数据而且没有设定 defaultNode 的话，会路由失败（如果有 defaultNode，则路由至 defaultNode）
【分片索引】5. 无论哪种模式，分片索引字段的格式化字符串 dateFormat 由用户指定
【分片索引】6. 无论哪种模式，划分不是以日历时间为准，无法对应自然月和自然年，且会受闰秒问题影响

运维注意点
【扩容】1. 带状模式中，随着 sBeginDate 之后的数据出现，分片数量的增加无需再平衡
【扩容】2. 带状模式没有自动增添分片的能力，需要运维手工提前增加分片；如果路由策略计算出的分片并不存在时，会导致失败
【扩容】3. 环状模式中，如果新旧 [sBeginDate,sEndDate] 之间有重叠，需要进行部分数据迁移；如果新旧 [sBeginDate,sEndDate] 之间没有重叠，需要数据再平衡

配置注意点
【配置项】1. 在 rule.xml 中，可配置项为 <propertyname="sBeginDate"> 、 <propertyname="sPartionDay"> 、 <propertyname="dateFormat"> 、 <propertyname="sEndDate"> 和 <propertyname="defaultNode">
【配置项】2.在 rule.xml 中配置 <propertyname="dateFormat">，符合 java.text.SimpleDateFormat 规范的字符串，用于告知 DBLE 如何解析sBeginDate和sEndDate

【配置项】3.在 rule.xml 中配置 <propertyname="sBeginDate">，必须是符合 dateFormat 的日期字符串

【配置项】4.在 rule.xml 中配置 <propertyname="sEndDate">，必须是符合 dateFormat 的日期字符串；配置了该项使用的是环状模式，若没有配置该项则使用的是带状模式

【配置项】5.在 rule.xml 中配置 <propertyname="sPartionDay">，非负整数，该分片策略以 86400000 毫秒（24 小时整）作为一份，而 sPartionDay 告诉 DBLE 把每多少份放在同一个分片

【配置项】6.在 rule.xml 中配置 <propertyname="defaultNode"> 标签，非必须配置项，不配置该项的话，用户的分片索引值没落在 mapFile 定义

为啥我应该为 MySQL 中的 varchar 选择 255 以外的任何其他长度？

【中文标题】为啥我应该为 MySQL 中的 varchar 选择 255 以外的任何其他长度？

【英文标题】：Why should I ever choose any other length than 255 for varchar in MySQL?为什么我应该为 MySQL 中的 varchar 选择 255 以外的任何其他长度？

【发布时间】：2011-03-10 20:25:11

【问题描述】：

我知道 CHAR 和 VARCHAR 的区别，

CHAR - 固定长度

VARCHAR - 可变长度（大小 + 1 个字节）

但我想知道选择 varchar 长度的目的是什么，例如VARCHAR(50)、VARCHAR(100)、VARCHAR(255)

这对我来说似乎毫无意义，因为实际使用的空间取决于存储在数据库中的值。

所以我的问题是：

1) 可以将我所有的 varchar 设置为 255 2) 为什么要指定其他长度？

【问题讨论】：

Are there disadvantages to using a generic varchar(255) for all text-based fields? 的可能重复项

另外，***.com/questions/1262174/…

一直认为 MySQL 文档很好地解释了差异：dev.mysql.com/doc/refman/5.0/en/char.html

请注意，如果您向 varchar 列添加索引：InnoDB 索引键前缀的最大长度为 767 字节。由于 MySQL 处理 Unicode 的方式，这可以进一步减少可以存储的实际“字符”的数量……使用 utf8mb4 编码，可能低至 191。所以对于索引列varchar(191) 可能是“最安全”的最大长度.在此处查看文档：dev.mysql.com/doc/refman/8.0/en/innodb-limits.html

【参考方案1】：

摘自MySQL documentation：

CHAR 和 VARCHAR 类型相似，但它们的存储和检索方式不同。从 MySQL 5.0.3 开始，它们的最大长度以及是否保留尾随空格也有所不同。

CHAR 和 VARCHAR 类型的声明长度表示要存储的最大字符数。例如，CHAR(30) 最多可容纳 30 个字符。

CHAR 列的长度固定为您在创建表时声明的长度。长度可以是 0 到 255 之间的任何值。当存储 CHAR 值时，它们用空格右填充到指定长度。检索 CHAR 值时，将删除尾随空格。

VARCHAR 列中的值是可变长度字符串。在 MySQL 5.0.3 之前，长度可以指定为 0 到 255 之间的值，在 5.0.3 及更高版本中可以指定为 0 到 65,535 之间的值。 MySQL 5.0.3 及更高版本中 VARCHAR 的有效最大长度取决于最大行大小（65,535 字节，所有列共享）和使用的字符集。

与 CHAR 相比，VARCHAR 值存储为一个字节或两个字节长度的前缀加上数据。长度前缀表示值中的字节数。如果值需要不超过 255 个字节，则一列使用一个长度字节，如果值可能需要超过 255 个字节，则使用两个长度字节。

【讨论】：

请注意引用时链接到来源。

一个小修正：链接的文档说VARCHAR MySQL >= 5.0.3 的上限为 65,535。引用：“The length can be specified as a value from 0 to 255 before MySQL 5.0.3, and 0 to 65,535 in 5.0.3 and later versions.”

【参考方案2】：

1) 如果您不想限制存储的 varchar 的最大大小，那么可以。话说……

2) 在许多情况下，您希望设置 varchar 大小的上限。假设您正在存储一个邮件列表，并且地址行的空间有限。通过为您的地址字段设置上限，您现在允许数据库为您强制执行最大地址行长度。

【参考方案3】：

1) 从技术上讲，这很好，因为在开始时创建的字段长度只有 1 或 2 个字节。之后，它们会根据需要生长。

2) 话虽如此，但良好的设计原则建议您适当设置字段长度，以便 a) 如果有人通过表格方案并试图计算出特定字段中存储了多少数据，他们可以看到某些字段将比其他人保存更少的数据，并且 b) 您可以防止数据库引擎完成少量额外工作，因为它必须在插入期间从 VARCHAR(10) 字段中截断比 VARCHAR(255) 更少的空间。

您可以在此处查看有关它的更多详细信息：

http://dev.mysql.com/doc/refman/5.0/en/char.html

【参考方案4】：

我在其他地方读到，当您对使用它们定义的列运行选择时，varchar 相对于 char 会带来性能损失。所以，也许你想选择 char，如果你确定该字段总是有一定的长度，并且你有性能问题......

【讨论】：

我想查看此声明的参考资料。

很公平，我会给你一个，只是这个评论是三年多以前的，我什至不记得我在哪里看到的。

【参考方案5】：

1) 是的。

2) 从历史上看，这是一个性能打击。

查看诸如 sqlite 之类的数据库，这些数据库将所有内容都存储为文本，以证明它不再重要。

【讨论】：

sqlite 并不是完全高性能的数据库 - 如果它强制行大小可变，则 varchar 会影响性能。

是的，但是对于大多数人和大多数人来说，它的速度足够快

没错，但声称它“不再”重要并将 sqlite 用作数据库工程的顶峰确实具有误导性。不，对于大多数人和大多数用途来说，它还不够快 - 它只是最容易配置并且超过成本，至少在最初......只要你从来没有来自多个用户的同时请求，就是这样。

【参考方案6】：

CHAR 与 VARCHAR

CHAR 用于固定长度大小变量。VARCHAR 用于可变长度大小变量。

例如

create table emp
(f_name CHAR(20),
 l_name VARCHAR(20)
);

insert into emp values('Suraj','Chandak');

select length(f_name), length(l_name) from emp;

Output will be

length(f_name)          Length(l_name)
   20                       7

CHAR vs VARCHAR的最佳答案

编辑

您可以设置列的最大上限。 性能和存储会产生影响。

谢谢。

【讨论】：

问题是“1）可以将我所有的 varchar 设置为 255 2）为什么要指定任何其他长度？”，而不是 CHAR 与 VARCHAR。

【参考方案7】：

在对字符串进行比较时，这两种值类型之间的主要区别就体现出来了。

在预定义长度的 CHAR 列中，您必须在整个列长度中一直“运行”，而在 VARCHAR 列中，您需要在整个值长度而不是列中一直“运行”长度，在大多数情况下更快。

因此，如果存储在 VARCHAR 字段中，则比较小于字段长度的值长度会更快。

【参考方案8】：

但我想知道选择 varchar 长度的目的是什么，例如VARCHAR(50)、VARCHAR(100)、VARCHAR(255)

这对我来说似乎毫无意义，因为实际使用的空间取决于存储在数据库中的值。

指定例如VARCHAR(5) 而不是 VARCHAR(500) 在某些情况下可以为您提供更好的性能，例如用于使用内存临时表的操作。

另一种情况是限制列长度以符合域要求（当您的值不应大于某个最大值时。例如：DNS 中的完整域名不得超过 253 个字符的长度）

【参考方案9】：

固定长度（静态）表更快。当表中的每一列都是“固定长度”时，该表也被认为是“静态”或“固定长度”。非固定长度的列类型示例有：VARCHAR、TEXT、BLOB。

http://net.tutsplus.com/tutorials/other/top-20-mysql-best-practices/

因此，如果您的表没有任何其他字段，即 varchar、text 或 blob；您可以使用 char 并使您的表格成为静态表格。这样他们会更快。

【讨论】：

那个答案与这里提出的问题无关。

你是对的。我不记得为什么我发布了这个答案。也许那时，我正在寻找相关的东西。也许他编辑了他的问题？

不知道，可能是。我不知道如何查看他的编辑历史，也不知道我是否有足够的声誉一开始就看到它。