“ 求实”
我们的工作很大程度上脱离不开mysql这个关系型数据库。我在工作中发现，在项目中大多数问题都出现在数据存储层面上。比如数据缓存方面，比如mysql慢查询方面。
想起之前项目中真实碰到的关于mysql方面的问题。在这里记录整理下。
有次迭代上线，晚上22点开始部署。临近部署前，产品经理又需要临时调整增大一个功能点数据。就这么个调整，部署时候，果然出现异常。最后排查发现，mysql text 类型字段超限了。
软件项目中临近部署还是尽量避免做任何功能调整。按照流程来讲，任何功能调整，研发要处理，测试要回归，整个流程工作量其实不小。
找了一条数据，把数据分析了一下，发现有63201个字符。
mysql的text类型，存储65535个字节数据。而现在的数据是63201个字符。这些字符是不是完全等于65535个字节呢？
我问旁边的同事，说的都模棱两可。看来这个case，要真正解释清楚。
看到末尾“上”这个字，知道字符串里面肯定存在中文。粗略浏览了下整个文本，发现确实由3类字符组成。中文+标点符号+英文大小写字母。标点符号和英文字母每个符合不论在哪种编码格式下，都占用1个字节长度。
通过在线中文统计工具统计，发现文本内容里面包括：1167个中文。
而这1167个中文具体占用多少个字节，需要根据具体的编码格式来计算的。
通过查看表结构，发现text字段编码格式为UTF8编码。而mysql中，中文在UTF8编码下，一个字符占用3个字节。
那么整个字符串的占用字节数据就是：（63201-1167）+ 1167*3 = 65535。
刚好65535字节。这下很详细的解释了上线部署异常问题。
记得还有一个关于int类型的细节问题。
有次面试，问候选人，int(3)和int(20)的区别是什么？
有一类人会说，int(3)和int(20)存储的数字大小不同，3和20各代表存储的数字位数（但其实，int最大存储不到11位数字）。
有一类人会说，两个存储的数字相同。只是显示位数不同。比如int(3)，存储数字5的时候，前面会补0，变成005。
对于第二类人，会补充询问，是否真正见过补零的数据。很大概率都会说没见过。
根据mysql手册来看：
int(M)，这个M表示显示宽度，最大值为255。
从最大显示宽度来讲，确实存在补零的情况。不过，补零需要对字段做一个特殊声明才能显示出来。即需要用zerofill来声明，如下：
补零后的结果如下：
如果设置M为255的话，它同样也会补零。即使只能存储10位长度的数字，前面依然会补齐很多个0。
绝知此事要躬行。确实要实践。
在践行知识的过程中，我们的经验才能得以很好的积累。