求 DBA 大佬，数据库表字段的注释管理相关问题

[odirus]

背景： 目前大多数因为用的是 MySQL InnoDB 引擎

在建表过程中，有许多类型字段，使用 tinyint 格式保证可扩展性，例如支付类型、订单类型、用户类型等等，但是随着业务的增长，类型种类越来越多，比如我们支付方式支持快二十种了。

问题： 经常需要帮忙做一些临时统计，了解数据表最快的方式就是看表注释、列注释，所以希望列注释越详细越好，但目前修改列注释的方式只有 alter table 的方式，这种方式到导致整张表进行重建，非常影响性能，也不安全

怎么保证在业务不断发展过程中，让字段的注释能够详尽呢？

现在想到的方案：

1. 把每种类型的描述写到文档中、代码中（道理都懂，大家都比较懒，谁愿意去翻文档）
2. 设计一张通用表，把不同的字段、描述都记录到这里面（但我并不想增加复杂性）

请求上面的方案是否有合适的，或者有更好的方法？

备注： imformation_schema.columns 中没有权限修改

[odirus]

自己坐沙发

[akira]

咦？字段注释不是另外去维护的么，怎么可能维护在线上表里面哦。

[odirus]

@akira 愿闻其详，讲讲你们的方式嘛

我们现在是写到代码和文档里面的，但每次做一些临时统计都要翻各种文档

[WuwuGin]

专门在开发环境写一个 get 注释方法，然后开发的时候直接以只读方式写进去。又不想看注释，文档，感觉这样比较靠谱。

[hcymk2]

同步一个空的数据库， 注释写在这个库上面。

[odirus]

刚刚我也请教了一下其他人，给出的建议是：建一个业务字段表，结构类似于,

seq_id, type_id, id, name

我们部分字段也是这样做了。但有些字段最开始以为只有一两种情况就没写进去，结果根据业务需求，类型越来越多，然后就尴尬了。

[wysnylc]

@hcymk2 这个可以

[depress]

我们 DBA 不是大佬，但是以下这套流程是她提的，给你参考。
开发人员会面对三个库，本地库、测试库、线上库。
线上库不维护注释，基于安全考虑。
本地库是开发人员自己电脑里的，随便改，供开发用。
测试库供开发人员测试用，和线上库结构一致，就是多了注释，但开发人员没有权限动结构。
如果开发人员对库有增删改需求，会先改自己本地库，不影响开发，之后向 DBA 提需求，DBA 在初建库时会维护一套数据字典文档，把所有字段和注释维护进去，如果是字段注释的修改需求，直接维护数据字典，如果是增加字段的需求，会先看数据字典有无相同意思的字段可用，有就直接用，没有就看开发人员提的字段名是否合理，合理的话维护进数据字典，完成需求后通知开发人员去测试库查看，开发人员再对应修改本地库和代码，当测试库测试没问题会对线上库做修改。关于测试库及线上库的修改都会用脚本在凌晨进行，顺序是备份整个库→备份会修改的表→做修改→上班后看运行是否正常，正常就删掉备份的表，不正常就恢复备份库。

[odirus]

@depress 感谢这么认真的回复