@Essaim 之前没评，也给涨过

@KaGaMiKun 12345 是啥意思

@Maxwe11 大佬有没有关于数据分层思想的资料推荐一下，想看看

@wxf666 不等，其他同事写的 SQL 都不好控制，再加上前期都是用外键关联查，有的 7 、8 个 left join ，随着业务数据增加有的大表 100 万数量级。

@pengtdyd 单独讨论技术方案，不扯其他

@lmshl 刚试过了，查询没问题,写入会提示锁冲突。

@Mithril 但是未来可能会增加表，也会加这个字段。还得改这个修改程序

@lmshl 嗯嗯，行锁也会影响查询

@xsm1890 加一些冗余字段是为了查询是方便。很多统计都会联表查询数据量大的时候就会慢

@lmshl 那些表有些都是记录表，有很多行数据。

@ipwx 那些表有些都是记录表，有很多行数据。

@chenqh 是的，现在起了很多端口一起负载。

@ipwx 是的，由于历史原因一句话也说不清楚，咱只聊技术。

@Dganzh 请求多了，后端服务接收不过来啦，导致前端超时卡死。我只是猜测你可以试一下。

多 upstream 几个端口出来试试。

=============这是我的解决方案===========
1. [后端] nginx 连接数调高、buffer 缓存调大、keepalive 加了长连接
2. [后端] 增加后台服务进程数
3. [后端] 慢接口进行读写分离优化（分析错误日志，找到转圈时刻慢接口）
4. [后端] 增加自动访问接口提醒功能(每分钟)
5. [后端] 增加了调第三方服务超时时间
6. [前端] 优化了超时时间 30 秒改 10 秒
7. [前端] 优化了页面快速切换的重复请求

三狗