如题，设计一张表，id这种自增字段该怎么选择类型？
光阴似箭催人老，日月如移越少年。
用自增的整数。
id INT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT
id一般来说不会是负数，所以用UNSIGNED。 id相当于身份证，不应该也不能是NULL。 至于为什么是整数，和两个因素有关：
id
UNSIGNED
占用空间。
效率。
MySQL的AUTO_INCREMENT不支持字符型。占用空间不用多说， INT类型固定只占用4个字节，能表示的范围达到了-2^31 (-2,147,483,648) 到 2^31 – 1 (2,147,483,647) ，设为非负之后翻倍，而使用字符串想要表示这么大量的数据...
AUTO_INCREMENT
INT
4个字节
-2^31 (-2,147,483,648) 到 2^31 – 1 (2,147,483,647)
效率则和索引的结构有关，MySQL使用B+树作为索引的数据结构，如果使用自增整数的话，插入数据时最多只会引起节点的分裂，而使用字符串则有可能会插入到任何地方，这意味着可能会引起节点的移动和分裂。其次是在数据查询的时候，字符串的比较也要比整数的比较慢。
B+树
分裂
移动和分裂
更多信息可以参考这个: 自增主键是否会降低数据库insert性能？如果会的话为什么还有很多公司采用？
最后: 我支持主键与具体数据无关= =.. 所以用整数最为主键是比较不错的选择。
数字型方便索引
用自增的整数。
id一般来说不会是负数，所以用UNSIGNED。id相当于身份证，不应该也不能是NULL。至于为什么是整数，和两个因素有关：
占用空间。
效率。
MySQL的
AUTO_INCREMENT不支持字符型。占用空间不用多说，
INT类型固定只占用4个字节，能表示的范围达到了-2^31 (-2,147,483,648) 到 2^31 – 1 (2,147,483,647)，设为非负之后翻倍，而使用字符串想要表示这么大量的数据...效率则和索引的结构有关，MySQL使用
B+树作为索引的数据结构，如果使用自增整数的话，插入数据时最多只会引起节点的分裂，而使用字符串则有可能会插入到任何地方，这意味着可能会引起节点的移动和分裂。其次是在数据查询的时候，字符串的比较也要比整数的比较慢。更多信息可以参考这个:
自增主键是否会降低数据库insert性能？如果会的话为什么还有很多公司采用？
最后: 我支持主键与具体数据无关= =.. 所以用整数最为主键是比较不错的选择。
数字型方便索引