# 故事
梅雨季，闷热的夜，令人窒息，窗外一道道闪电划破漆黑的夜幕，小猫塞着耳机听着恐怖小说，辗转反侧，终于睡意来了，然而挨千刀的手机早不振晚不振，偏偏这个时候振动了一下，一个激灵，没有按捺住对内容的好奇，点开了短信，卧槽？告警信息，原来是负责的服务出现慢查询了。小猫想起来，今天在下班之前上线了一个版本，由于新增了一个业务字段，所以小猫写了相关的刷数据的接口，在下班之前调用开始刷历史数据。
考虑到表的数据量比较大，一次性把数据全部读取出来然后在内存里面去刷新数据肯定是不现实的，所以小猫采用了分页查询的方式依次根据条件查询出结果，然后进行表数据的重置。没想到的是，数据量太大，分页的深度越来越深，渐渐地，慢查询也就暴露出来了。
# 故事
会议室里，小猫挠着头，心里暗暗叫苦着“哎，这代码都撸完了呀，改起来成本也太大了。”
原来就在刚才，组长找到了小猫，说代码review过程中发现有些数据表模型设计得不合理，要求小猫改掉。小猫大概是设计了一个配置表，为了省事儿，小猫直接把相关的配置设计成了text类型的存储形式。
关于这种业务场景下使用text文本类型存储，组长指出了以下缺点：
- 在内存中处理Text字段时，由于需要处理大量数据，可能会导致内存使用过度，影响数据库性能。
- Text字段无法创建索引，这会导致数据库在执行查询时无法利用索引来加速搜索。虽然可以通过全文索引来改善搜索性能，但是却会有诸多限制，例如只能用于InnoDB引擎，并且索引只能建立在不超过1000字节的前缀上。
- 目前刚设计的时候就用text类型，后期随着数据量的增长以及业务需求的变化，可能就意味着要将text类型继续扩大变成，LongText或MediumText类型，这样的转换既费时又可能需要额外的存储空间。
“组长说的也有道理，但是为什么现在才指出来，当时方案模型评审的时候咋提呢，哎，醉了醉了，现在业务逻辑都按照现有方案开发完了，才提出来.....”
“改？要重写逻辑，不改？万一今后真的出现上面组长说的这些问题，不得被喷死......”
彷徨过后，小猫终于下定了决心，改了吧，长痛不如短痛...反正如果不改的话，受罪的还是自己。于是加班是少不了了......