这是学习笔记的第 1817篇文章
在我们的工作中，其实我们对于自己所负责的数据库是不够清晰的，比如我们了解自己所负责的数据库中表，索引分布情况吗？这里我们不需要给出具体数字，而是有一个大概的比例就可以。 我想大多数人会忽略，一方面他只关注于他需要了解的业务，所以不需要关注额外的信息，另一方面因为权限等原因，他无法获得这些信息。
这些信息对于他来说，有没有用呢，其实是有的，如果一个数据库里存在上万张表，毫无疑问这是一种很糟糕的设计方式了。如果业务能够获得这些信息，他就不会像选择黑盒的处理方式一样不断的往里面填数据，这种改进是隐形的，另外我们制定了开发规范难以落地，一个原因就是信息不对称，你说这些信息是不是机密，显然不是，所以这些信息是我们可以共享给业务同学的。
这些信息对于DBA来说，有没有用呢，其实也是有的。我们处理问题，也是由被动模式变为主动模式，能够提前发现问题比遇到问题再解决的意义大得多，当然这种方式难以体现业务价值。我们换一种方式来理解，那就是我们主动反馈给业务同学，他们现在的数据库使用放存在哪些隐患，我们给出具体可行的建议，让他们也参与进来，我想这就是一种共赢。最终的结果是一样的，问题得到了解决，而且是商量着来的。
那么对于这件事情如何落地呢，一种是数字化，一种是可视化。其中可视化的方式体现的效果更好一些。
比如你看到这个数据库对象的分布情况，会有什么样的印象。
可以看到这个库中有700多张表，主键比例和表数据量持平，说明整体的设计还不错（当然从比例来看少部分表还是没有主键的），但是值得一提的是，整个数据库中的辅助索引比例过高，为什么加索引，本质上是为了查询快捷，辅助索引比重高，说明整个数据库的类型还是考虑了较多的查询需求。
这个库里的对象分布如下：
这个库的场景比较单一，只有表和主键，整体来说，和偏日志型写入的业务相关。
这个库的对象分布如下：
可以看到，表和主键的比例基本持平，含有少量的辅助索引，还有一部分的存储过程，在MySQL里面含有存储过程不是一种很良好的设计，一种可能是遗留问题，一种就是涉及了一些复杂的业务逻辑，但是可以确定的是，这个库是很难以做分布式扩展的。
这个库的对象分布如下：
这是一种相对理想的对象分布方式，表，主键：辅助索引的比例为4:4:2
没有存储过程，函数，从业务的角度来说，后期要做扩展和改进都是比较容易的。
