@bitfly #59 哈哈哈 这不就是 ck 嘛，造成一个大宽表

@adoal #58 这样也没 OK ，唯一的问题是如果数据发生变动了，那宽表的数据不是得跟着变

@zhoujinjing09 #56 谢谢回复，请问 ck 中多表关联查询的性能怎么样，也在考虑将慢查询迁移到 CK

@wxw752 #48 ，谢谢，我去咨询一下客服

@baibaibaibai #51 ，谢谢。我去看看怎么做
@mark2025 没有专职的 DBA ，这样做风险太大了

@adoal #44 是后者 @lvlongxiang199 #49 。同时请问下二位大佬，clickhouse 我不太熟。翻了下文档好像 ck 对 join 的支持不太好？ 那我如果将部分大 SQL 涉及到的表 以关系型数据库的原表数据导入到 ck ，并在 ck 中进行 join 关联查询等是否可行？ 谢谢

@baibaibaibai #43 那么如果数据发生变动了，也要同步更新 ES 的数据吗，因为是查询后的数据同步到 ES ，更新逻辑也会很麻烦把？

@heiya #39 谢谢回复

1 、ES 关联查询不如数据库那么方便，如果将查询后的数据汇总到 ES ，又涉及到数据变动更新的问题，不管怎么做都很复杂
2. 我是 RDS SQLSERVER WEB 版，目前来看只支持 DTS ，其他都不支持。

@blackeeper #36 只能走阿里云的 DTS 做只读
@baibaibaibai 您的意思是，落库后的数据，根据复杂 SQL 查询出来后的结果再写入到 ES 吗？

@z1829909 #32 哈哈哈 大家一起痛苦
@opengps 是这样的，但是因为没有审核 review 机制，真的很难推行，更何况是几年的老代码
@Atoony SQL 中包含了很多业务逻辑，AI 的效果也不好

@z1829909 人力更不够(笑哭)，而且 SQL 强关联业务，又不可能扔了业务需求完全不做来改 SQL 。

@ala2008 这个真迁不了 哈哈哈 工作量太大了
@heiya #28 谢谢大佬的回复，原先的方案确实不合适，我已经否了，现在在考虑新的方案，主要是解决如何避免数据库挂了，以及如果数据库挂了如何保证业务可用的问题，针对您说的这几点我概括一下，您看我说的对不对

1. 如果是将大数据量的表同步到 ES ，那如何解决关联查询的问题？ 还是说将关联查询的结果直接同步到 ES ？

2.阿里云的 rds sqserver 好像不支持从库，只能通过 DTS 同步。

3.索引是肯定有的，但是数据量太大，优化的工作量也不小，目前同步在做；

4.将核心业务迁出来，包括代码和数据库，避免影响到核心业务。

5. 分库分表暂时没有

6. 慢 SQL ，大 SQL 的报警都有，但是优化难度很大

7. 业务上的限制条件也是有的

8. 问了阿里云客服，除了买高可用和 DTS ，没有其他方案，自己做了部分冷数据的备份，但也仅仅是备份

9. 更换数据库成本太高了，而且领导层不一定支持，我综合一下方案往上提

@blackeeper #21 是这样的，越是不可用的时候，用户越会不断重试刷新，因为解决这类问题，不是一套工具或者一个方案能解决的。相关的熔断限流都有，现在想解决的是数据库挂了的问题；
@mangodai #22 有这个能力就不会问这个问题了 哈哈哈
@0x663 #23 根本问题就在大 SQL ，但是远水解不了近渴，得先想数据库挂了如何处理的问题
@bellx #24 核心业务少，SQL 优化耗费的时间和精力都能接受
@ala2008 #25 好像 sqlserver 不支持从库

@goodryb 是的，这个方案目前来看不合适，用 Redis 做查询缓存层更合适一些

@cccb 谢谢，我看一下
@goodryb #14 正常流程肯定是当做读的缓存来用，就是考虑数据库挂的了情况下，如何解决的问题
@fatyoung #15 最大的几张表已经过亿了，做了数据库拆分，在太复杂 SQL 的情况下，一张表即使只有 1 2KW 的数据，查询也是有风险的
@adoal #16 请问有什么好的方案吗？ 谢谢

@bg7lgb 最常见的情况就是因为 SQL 太复杂，表数据量又太大，引起数据库 CPU 过高导致数据库服务不可用，一般重启就能解决，但是也要将近 10 分钟时间。配置目前是 16C 32G 次高，在网上就是顶配 16C 64G 。业务压力点是夏天，时间大概有 2-4 个月。

@Varobjs 谢谢大佬，我司用的是 sqlserver

@SoulSleep 谢谢大佬的指导

1.公司买的是阿里云的 RDS sqlserver ，除了 DTS ，不支持其他方式做主从或者读写分离；
2.精简在线业务库的单表大小、做慢 SQL 优化、优化业务逻辑 这些都有在做，也在拆分核心业务，但是数据库这一层始终没有非常好的办法解决。

列存数据库您具体指的是哪些？

@bg7lgb 大佬说的是，这样加东西，只会增加复杂性和排查问题的难度，最根本还是得优化 SQL 。

有没有什么其他好一些的方案？ 因为 SQL 优化是一个很漫长的过程，其中还牵涉到很多老的业务逻辑，那些 SQL 和表我看过，给我的感觉是一天能改好一个都已经不错了。

@evan1 @bg7lgb SQL 优化已经在做了，但是远水解不了近渴。