文字工作应该还 OK ，如果编程的话怎么跑 IDE 和开发环境？

@airplayxcom beego 的 orm 恶性到吐；而且不支持 application/json 类型的请求参数直接解析到结构体中，还得自己 json 解析。冲这 2 点就真的放弃了

@neptuno 道理其实都懂，毕竟大家都是打工人。最大的问题就是数据库设计不合理，这样我后续开发起来，进度会拖很久

@noparking188 Collation 有好几个：utf8mb4_general_ci 、utf8mb4_unicode_ci 、utf8_general_ci 七七八八的

@noparking188 一个数据库出现了四五种字符集，你觉得能有什么规范吗

@msg7086 前提是要有人懂，并且有一定的话语权来推动呀；我们这边部门领导一般不管这些，主要负责全局的把控；后端组长自己就是写这些代码的人；我是一直想要推动，奈何没什么话语权，所以挺难的

@potatowish 外包都比这好

@fengpan567 无，代码评审推不动

@wangxin13g 命名都是小问题，一会就改好了，关键是数据库设计和逻辑实现烂

@tiktokxxxx2020 我不想吃，但是我要领这份工资，所以身不由已。领导说这个项目你接受，难道你能说代码太烂了我接手不了

@gancl 不会，只会保存字段，具体的关联代码中处理；不过这人把关联字段用逗号拼接成字符串，特么的啥都做不了了

@ychost 对的，数据库是 IO 最重的地方，应该花大力气来处理；加缓存虽然效果明显，但是会导致代码复杂度增加和缓存同步问题

@noparking188 无，一个数据库出现 4 种字符集，join 都用不了；字段命名没有规则，大家各做各的

@shot 团队负责人虽然也是技术出身，但是自己并不写代码，主要是注重开发进度和应用稳定性，技术主要让组内一个有一定年限的同事来处理，但是这代码就是这个同事写出来了，所以就不要指望他能做啥优化了。

目前数据量在三千万左右，每个月增长差不多 200w 左右，sql 性能问题已经慢慢显露出来了。

@unregister 也可以，join 不是万能，解决问题的方案有很多种，

@msg7086 因为 n+1 问题，我们目前部分接口已经出现明显的性能问题了，但是有些人都不重视这块，一直在优化语言级别的性能

@namelosw 对的，解决一个 n+1 问题，比你用什么架构缓存都好使，除非就是为了装逼

@anouser 用户量大概十几万吧，日活 1 万左右，做垂直领域的，量不算多，但是还是有用户用的

@crazycarry 如果数据量不大百万级别，并发量也不大，加 es 或者 redis 的意义在哪里？