应用系统的数据治理一些关注点

 不要过度设计，每个系统都会有些表的字段从来没有值，可能是当时预留字段，但是现在看来，很多预留字段都是浪费的，建议还是真正需要时再添加不迟

 无论是做数据结构设计还是sql的编写，都应该控制复杂度，复杂的sql会导致数据库load的冲高，当PV上来时，系统响应变慢，然后系统请求堆积，严重的最后会导致整个系统完全无法提供服务，所以每个开发童鞋写sql时需要优先考虑性能问题，让每条sql尽量简单，都能走到对的索引，通过应用程序去解决复杂的sql逻辑查询

 不要把所有数据都丢到数据库，特别是数据量大的日志型数据可以通过日志输出，通过elk／flume+storm等方式拉取到es中进行查询跟踪，如果硬是要保存到数据库，那只需要保存异常数据即可。用户行为数据可以发送消息出去，由其他应用来监听消息并且保存到Redis／MongDB中，比如登陆相关数据，投资行为等数据，如果这些数据需要用来做业务流控，如现在登录次数等业务场景，可以使用redis的数据过期机制来实现

 不要给用户太大的空间进行数据的输入，尽量提供选择框让用户选择，防止脏数据的产生，关键字段要设置为必填，否则会给数据分析时的数据清洗带来麻烦

 设计好表的UK，可以避免数据的重复，也可以给接口的幂等性提供支持

 对于数据量大的业务处理建议使用异步化的方式来实现，通过发送消息的方式进行数据分片，然后可以对数据进行分布式处理，提高数据处理速度

 对于大表，首先考虑数据库的优化，然后再考虑读写分离，是否可以做分区表，数据归档来提升性能，最后才去考虑进行分表分库的设计，分表分库无论对于系统本身的设计开发很难的把握，同时对于数据的使用者也是增加了复杂度

 对于缓存数据的使用，尽量不要缓存用户唯度的数据，这种类型的数据不但给缓存服务器带来压力，更主要是缓存的命中率低，所以对于缓存的使用也是设计的关注点，不要因为某个缓存数据的暴增而拖垮整个缓存服务器

 随着数据量的积累，有些数据过了其的生命周期，也就是说这些数据变成了冷数据，没有系统需要再使用它了，那么我们就要定时的去做一些数据的归档，腾出数据库资源给热数据来使用

 涉及数据量大的更新，如某个表新增的非空字段等，建议分批进行更新。分批不但为了数据库的稳定，防止引起数据库的死锁，同时也防止ETL工具拉取大量的更新数据，因为很多报表需要依赖ETL同步完成数据，如果ETL同时超时的话，很多定时报表会运行失败，有可能需要手工再次运行报表任务，所以进行大数据量更新时，一定要通知DBA和数据团队进行跟踪关注。

 监控是最后的守护者，可以及时的发现系统的性能问题，对于数据库来说，

 DBA可以通过数据库的监控工具来实时的对数据库进行监控，对于核心表的数据量增长趋势，核心表相关的sql查询性能都需要进行跟踪。但是提前发现sql的性能问题，进行合适的预防则是开发团队需要关注的。这就需要监控中心对sql的运行时间和次数等指标进行跟踪和汇总,如果当前没有监控中心，也可以使用DruidDatasource的statFilter功能进行跟踪，开发团队需要定时的去关注sql运行时间，运行次数等指标，随着业务量的增长，之前高性能的sql可能会变慢，高频sql绝对不能出现在long sql的列表中，需要及时改造。还有就是缓存服务器的监控也是需要关注的。