工作也有三年多的时间了，虽然架构能力很一般，但是也有自己的一些看法。目前公司的项目基于springboot框架而建，其实这个选的还是可以的，毕竟可以快速搭建spring应用，快速集成第三方框架，而且以后如果要做微服务，不管是springcloud还是dubbo都能很好的集成近来，改动代价也不是那么大。而持久层框架选了spring data jpa，后面也试着跟前辈们谈过这个架构，他们说当时就是为了快速开发而选用jpa，对于这个框架我是真的不懂，也不好多说什么，只知道对于某些查询确实不需要写sql。当时一个同事私下里跟我说jpa不支持列裁剪，意思就是只支持select * ，这一点我目前还没有证实，有时间我会去证实。如果这个说法是真的我觉得那这个项目的技术选型真的很有问题，但我觉得像jpa这种框架应该不会出现这种问题或者有其他方式可以解决这个问题，这里我先保留我的意见。
我要讲的是表的设计真的很不合理，表也是通过jpa框架生成的，可能jpa真的能省很多事，我发现好几张表都有两个或以上的外键这种强关联性的东西，很多时候其实并不需要查关联表的数据，也不需要查那么多的字段，下面我将举例说明：
我要做的需求是消息推送，其中有种场景是需要推送给所有用户，那么就涉及到查用户表全表，我查了一下，不到10万数据，这个用户表关联了两张表，表数据我暂时没查，我也不关心了，我直接通过postman调接口然后断点到查表的那一行，起码三四分钟没有返回，试了几次都是这样，我不敢再试下去，每次都是以停服务为结束。后面我直接在navicat上通过sql语句全表扫描，不到10万的数据1.8S返回，然后只查需要的字段0.6S，很明显列裁剪是比较有效果的。用户表61个字段，包括关联的外键，实际上用到的字段不到8个，其中有一张关联表实际上都用不到，这样，这种强关联的弊端就体现出来了。虽然我不是数据库大神，虽然设外键貌似能省事，但涉及很多增删改查的场景的时候也会很多坑，这一点我还是比较明白的，个人工作经验来讲，一般不会设置外键。这个问题其实我反馈过几次，但徒劳无功，我也知道，因为项目跑了这么久了，架构层的东西再改是很难的，所以我很担心以后用户量多了的时候会怎样。在上一家公司，当时除了做jvm调优，代码层能做的优化我们做了很多，说实话，列裁剪的优化效果还是不错的，特别是在数据量特别大的情况下，对减少内存和IO这一方面效果都不错。
综上所述，一个项目在初期的规划就必须做好，后期再调整的代价是很大的，一个好的架构师或项目搭建者应该拥有更长远的目光，应该考虑到当前大数据时代下的后期优化和扩展，不能为了省事而剥夺成为一个好架构的机会。当然，这也只是个人看法，毕竟本人水平有限，也许到了真正的大牛手里，这些都不是事。。。