Question

我有一个mysql数据库，我在其中定义了一个表：

CREATE TABLE IF NOT EXISTS tblModel (
model_id int NOT NULL AUTO_INCREMENT,
model_file varchar(50) NOT NULL,
model_name varchar(50) NOT NULL,
model_descrip varchar(200) NOT NULL,
target_index char(6) NOT NULL,
training_days int NOT NULL,
trading_days int NOT NULL,      
PRIMARY KEY(model_id));

奇怪的是，我注意到虽然mysql文档说int是真的int（4），但我看到int字段实际上是作为int（11）创建的。这有点令人不安，因为根据文档，似乎没有遵循我的指示。

当我使用mysqldb.database_connection.cursor将此表查询到python时，我看到这些内容正在经历多长时间 - 这并不奇怪。

因此，我的问题是三重的（按照对我越来越重要的顺序）：

1）知道为什么int被创建为int（11）？

2）此表中的int字段将包含序列＃，并且日计数 - 分配给long的空间不太必要。我应该关心浪费的空间吗？

3）假设我坚持使用int（11）（其他表中有外键，并且打破并重新创建所有内容有点痛苦），有没有比做一个显式转换更好的解决方案cur.fetchall（）或cur.fetchone（）的int返回？

Answer 1

这是默认的显示宽度，因为int可以在-2147483648到2147483647的范围内，因此最大显示宽度为10个整数和一个符号。无论其值如何，int的存储大小都是4个字节。不要将“显示宽度”与存储大小混淆，因为显示宽度仅在数字具有“zerofill”选项时才显示，因此int（4）zerofill将显示0004，而int（6）zerofill将显示000004;这是最小显示宽度，因此使用123456的int（4）zerofill仍将产生123456而不是1234.查看http://dev.mysql.com/doc/refman/5.5/en/numeric-type-attributes.html
空间可能浪费也可能不浪费，取决于架构和操作系统。在C中，int必须至少为16位且长至少为32位，但可能更大。在64位系统上，long实际上可能是一个很长的长64位。除非您在严格限制的系统上运行，否则可能不值得担心。这只是在内存中，因为MySQL将这些整数存储为4个字节，无论Python使用它们做什么。
如前所述，（）中的数字只是一个显示宽度，并不影响该列中数字的基础范围，尽管如果你在一个表上执行类似int（4）zerofill的操作一个外键和int（6）zerofill在另一个上，连接可能很奇怪，但我还没有测试过。将“zerofill”添加到MySQL编号会使该列自动无符号。从MySQL中读取这些内容时，您不需要进行任何操作; ints适合长期存在而且Python存储都是C long，无论如何。

mysql int被传递给python一样长

1 个答案: