写这篇博客的原因是在建表的过程我建表时，在表名和字段名上没有注意，违背了团队的开发规范。我们团队规范是，名字上要能够体现对象的特征。
比如：
数据库要写db_dbname
表名要写tb_tbname
字段名为f_fieldname
有规范在团队开发中，虽然略显不灵活，不过时间久了，这种优点就会凸显出来。代码的质量和可读性也会提高。
在工作中犯的另外一个错误是，对于数据库字段大小的不合理使用。比如int varchar。使用int 的使用，建表习惯性写int(50) 或者int(20)。这样写没有出过错，mysql也从来没提示我这样写有什么不对。直到主管质问我，int最大最有11,知道吗？我歪着脑袋想了半天，想到以前都是这样用的，还讨论了一番。主管也懒得给我讨论这种低级问题了，网上查找了一番，觉得解释的都不够精确，不到位，有些还误人子弟。于是回到家重新翻开书，修正这一块的错误认知。
在实践中tinyint 的默认最大长度是3 255（长度3）
smallint的默认最大长度是 5 最大值65535（长度5）
mediumint 的最大长度是8 最大值是16777215（长度8）
int 的最大长度是10 ，最大值是4294967295（长度10）
bingint 的最大长度是20位。
也即是你设置了tinyint(1) 最大值也是255.
不会因为设置的大就多存数据。例如tinyint(5) 最大还是只能存255.
那么以后写数据类型的时候，还是尽量不要设置后面的长度，使用数据库自带的长度即可。
那么还有一个误区，总会认为text 字段类型比varchar 可以容纳的字符多，看了书后才知道。它们的最大字节数都是65535。使用时要根据具体的字符集来换算。
char 是定长字符串，跟字符集无关，跟最大字节数也无关，但最多只能容纳255个字符，在中文中是255个汉字，在英文中就是英文字母。
如果不了解这个差异，有时候将博客文章直接放进数据库，就会出现存不进去的错误，如果再不懂得查看mysql的错误码，就要折腾好久一会了。
在实际工作中，同事就因为这个字符大小的问题折腾了挺久，建议存放纯文本还是使用mediumtext 或者longtext 字段。
当然可能很多人不在乎这种细节，可是程序的健壮性、优雅性就是通过这种细节一点点体现出来的。现代外存的价格已经很低，使得不用考虑数据占用空间的问题。但是更要关注效率，如何以合适的字段类型，占用合适的字段空间，使得程序运行的更快。快是这个时代的主节奏，你细节处不在意，程序就可能到处都是可以优化的case，慢的地方多了，就拖慢了整个程序，用户体验变差比不过竞争对手，从而导致一个尚不错的产品在市场的竞争中落败。