数据库版本
阿里云 RDS SQLSERVER
需求
需求是因为老项目的长 SQL 实在是过于多了，几百行的 SQL 一找一个准，去优化 SQL 工作量非常大。
导致生产环境数据库很不稳定，经常因为 SQL 引起数据库不可用导致被客户投诉罚钱，问了阿里云他们推荐高可用集群，但是阿里云高可用对于小企业来说实在是太贵了。迁移下云又需要比较专业的 DBA 来运维数据库，小企业老板估计也不会同意。
做了什么
已经做了这几步：

使用了 DTS ，同步主库的数据到从库，基本上实现了读写分离；

拆分了核心业务，但是核心业务仍然有访问数据库的需求，因此万一数据库不可用时，如何保证核心业务的正常运行，成为了一个大问题；

想做什么：
领导提了一个想法：能否通过在中间加一层缓存层的方式，比如 Redis ，核心业务的增删改查先走 Redis 。一段时间后落库，这样即使数据库挂了，只要能撑住 10 分钟数据库就能恢复。
其他方案：
将数据库和接口都进行拆分，拆成多服务，需要对应数据的，走接口进行查询调用
不知道有没有其他更好的方案，求大佬们指教，谢谢~

那 Redis 挂了呢

Redis 是集群，并且开了 AOF

我遇到的项目都是先加监控，定位慢 SQL 然后进行针对性的优化，比如加索引，分库分表之类的。

没有遇到过用 redis 做这种中间库的。

数据库优化，从应用开始，而不是从数据库层面入手。

老老实实查日志，找慢 SQL 优化。

Redis 做缓存，增加了技术的复杂性，故障节点也多了。

而且目前这个问题也不是用高可用版本就可以解决的。

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

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

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

redis 缓存有个项目叫 readyset ，可以兼容 mysql 协议，数据库连接可以直接改为 readyset 端口，默认 sql 都会直连数据库，可以在控制台指定 sql ，走内存

+1

不解决问题，要靠堆配置是最后的选择，又不舍得花钱，这不是既要又要吗？
阿里云的 dts 使用场景主要是异构数据库，相同数据库直接开主从就好了....

再就是如果分析型 sql 过多可以考虑用列存数据库、可以考虑加读写分离。。。但是归根结底

必须要做的：
精简在线业务库的单表大小（做做历史归档？）
做慢 SQL 优化（加索引、改写法、做限流...)
优化业务逻辑（如同步改异步）

谢谢大佬的指导

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

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

谢谢大佬，我司用的是 sqlserver

挂的时候是什么情况？系统响应慢导致服务不可用？还是直接崩掉了？

最直接的方法就是升级配置，先缓解一下，争取点时间来优化。

可以参考，redis gears write-behind

redis 本质是做缓存的（不乏一些开了持久化当数据库用），提升查询效率，正常写逻辑都是要直接写库

而且加缓存业务也得改，不如好好投入精力，优化 SQL ，短期来不及就先升级配置，后续改好了再奖降回去

用 redis 做只读缓存应该可以分担很多数据库压力吧？看描述应该是数据量不大，只是 sql 执行时间长吧？

这种典型的传统信息化型应用的性能瓶颈问题，就不要指望能直接套互联网基础设施来速成了。

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

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

redis 增删改查,定期同步到 db,在游戏业务服务器上,是比较常见的方案.
但这种方案,仅针对单条记录的线性的增删改查.

但如果复杂业务复杂 sql,比如涉及跨表查询,比如 事务性的多表修改,加缓存层 实现起来也比较麻烦吧? 何况还得考虑并发等情况.
具体还得结合你的业务场景,看起来是复杂 sql,目测不适合.

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

感觉你需要的是一个网关，对流量进行拦截，限流，限频。从而服务降级，来保证数据库不崩溃。
当你数据库慢的时候，前端不断的重试，刷新，加重数据库的卡死。

要看业务规模 和 架构。
redis 确实做过库存扣件最后落 db 。
infoq 写过快手等电商系统， 对于直播超大秒杀百万 qps 直接走 redis 。
你们有这个业务场景，和维护 redis 库存的技术能力吗？

感觉和数据库容灾没啥关系，和你们项目的脏 SQL 关系更大。
即使做了容灾，运行这些 SQL 还是会出现问题。

如果核心业务也涉及复杂的查询，那怎么堆配置都是没用的，根本问题解决不了，还是得老老实实优化查询。

1 、缓存肯定要加的，你说的 sql 复杂，估计查询也慢
2 、阿里云应该直接支持配置从库啊，不用自己搞
3 、sql 优化吧

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

那 sqlserver 够垃圾的，迁移到 pg 或 mysql 吧哈哈

SQL 太复杂，一查几百行，表数据量又太大 导致大量的慢 sql ，是不是瓶颈在于查询而不是新增和修改？这样的话我感觉用 Redis 替代 Mysql 查询不合适，原因是即使前台没有显式的调用这些复杂 sql ，在相关业务进行新增和修改时也调用复杂 sql 同步到 Redis ；如果说不调用 sql 直接将数据存到 Redis ，那能不能确定由复杂 sql 组成的数据可以通过简单的 Redis 命令重新组成，我感觉挺困难的；还有数据量太多的话假设 Redis 挂掉，AOF 恢复是需要时间的，在这段时间内服务不可用；综上，我感觉 Redis 不合适。 解决办法根据描述我感觉：1.针对那些很复杂、数据量又特别多导致慢 sql 的表，将这数据同步到 ES 的一个索引中，组成一个大宽表，所有有关的复杂查询全走 ES 2.每次新增或修改时使用消息队列同步到 ES ，不能直接同步（或者现在有一些同步组件可以用） 3.如果有很多复杂查询但彼此不相关就需要多个索引了 4. 如果条件允许的话针对这些复杂的查询单独拆出来组成查询服务 5.分库分表还是有必要搞的，不过根据我的经验用过 Sharding 和 Mycat ，复杂的 sql 还是歇菜 6. 优化还得继续，慢 sql 报警不知道有没有 7.业务上能不能限制一下查询条件，比如起始时间什么的 8.有没有数据冷热分离的可能性？ 9.据说 PG 很强，但我没有用过，得试试

定期捞慢 sql ，然后拆分优化或者跳过。既然你们钱不够，那就靠人力解决。
不是很赞同直接引入 redis ，可以分析出慢的地方，sql 优化成本很高的时候，针对这一部分做一些缓存。sql 虽然几百行，但是多花一些时间，逐步分析，测试到位问题不大。

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

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

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

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

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

5. 分库分表暂时没有
6. 慢 SQL ，大 SQL 的报警都有，但是优化难度很大
7. 业务上的限制条件也是有的
8. 问了阿里云客服，除了买高可用和 DTS ，没有其他方案，自己做了部分冷数据的备份，但也仅仅是备份

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

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

   或者组里安排一个人专职优化 sql ，或者轮岗，每人定期来一波精神折磨 233

   复杂 sql 本身就是业务设计时候应该避免的

   可以试试让 AI 优化 SQL ，说不定有奇效

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

   都已经确定是数据库的问题了，那就从数据库优化着手。
   1,买几个虚拟机，整多个只读实例，卡死一个，不影响全局
   2,优化数据库服务器的性能，换 SSD ，32G 内存太小，建议加大内存，配置数据库 cache 大小
   3,排查优化慢 sql ，增加相关索引
   4,把旧的数据归档，很多 sql 每次几亿的全表扫描是很消耗资源的。

   查询从 es 走，落库后组织数据写 es

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

1.这个需要你们去分析。可以将关联查询出来的数据结果集作为一个大宽表同步到 ES 的索引中，这个大宽表可能有很多字段；也可以在后端业务逻辑中将需要的条件提前准备好了直接传递给 ES （如果被 jion 的表查询很快的话）；还有一种是 ES 的索引间关联查询也可以。
2.有一个数据同步中间件 datax ，可以将 Mysql 的表数据同步到各种其他数据库。
4.我感觉是哪个工作量相对小就将哪一个迁出，目标就是避免影响到核心业务。
10.还有一种查询是各种聚合查询，针对于各种大数据量下的 count 语句，那 ClickHouse 特别合适，不过使用他是有条件的，只有写入和查询的话可以使用。
11.前端页面上点击查询一时半会返回不了就不要再发送相同请求了

整体上我感觉就是现在的 Mysql 满足不了复杂的查询业务，把整个服务拖垮了，并发量其实并不高。最要紧的是把 1 和 4 搞定，其他的 6,11 同步做。不过，这么一搞就把技术复杂度提上去了，新增了 ES 和消息。

＃39 谢谢回复

1 、ES 关联查询不如数据库那么方便，如果将查询后的数据汇总到 ES ，又涉及到数据变动更新的问题，不管怎么做都很复杂

2. 我是 RDS SQLSERVER WEB 版，目前来看只支持 DTS ，其他都不支持。

   是的，我们是这样做的

   要么改代码, 要么加机器...

   根据业务复杂查询扩展 es ，单行复杂数据横向扩展进 es ，损耗一点增删改的接口效率，但是基本也忽略不计

   你那些大 SQL 是什么类型的，事务型还是分析型，如果是前者，没啥好办法，只能硬着头皮一点一点改了。后者的话，可以考虑同步到数仓里做分析，但是结果可能不会跟事务库完全实时一致。

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

   至于换数据库，千万不要幻想 PG 比 MSSQL 性能好……至于 MySQL 想都别想了。

   人家用的 MSSQL 你讲 MySQL 满足不了复杂的查询业务……

   你这题我会，我们公司用到了大量各类阿里的云服务。

对于你们来说，不要动 SQL ，最好的解决方案确实是读写分离，但读不要再用 RDS 了，用 DTS 将主库的数据同步到 AnalyticDB 中，这个阿里云的数仓和 mysql 的语法完全一样，SQL 查询效率直接拉满，一行代码不改，JDBC 直接连 ADB 读就完事了。

复杂查询估计是 AP 类型的, 建议上 clickhouse/Doris

救急的话, 与其上 redis 不如考虑拆分实例, 核心服务读/写单独的实例, 通过 DTS 把数据同步到复杂 sql 读的实例, 这样开发的工作量小些

＃48 至于 ES ，只有在需要全文检索这种特定场景的表才会存 ES 。

所有数据全部存入 ES ，对于你们现阶段绝对绝对不是一个可选项。

是的，更新逻辑放到原有修改或者走消息都行吧。

自己购买服务器，存储上固态，放 IDC 机房。性能会比云高得多。

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

＃48 ，谢谢，我去咨询一下客服

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

别盯着笔误挑毛病，我写成 abc 他那不还是不行？最烦你这种人，啥方案提供不了就知道挑别人毛病。你觉得你行就给人家一个方案，觉得我说的方案不行就指出哪里不行。逼逼赖赖显你有嘴了。

DTS 到 OLAP 数据库，ES/Redis 纯属歪门邪道

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

Clickhouse 之类数仓的玩法是把复杂查询“预处理”生成宽表，这样查起来在宽表上就快了，所以，结果可能不会跟事务库完全实时一致，你要先想明白这是不是你要的目标。

我也遇到過這種問題
用用了一个简单有效的极速无脑一把鑠的办法
就是监控出最吃 CPU 的语句 可能查询超时那种

提前把他查出来存一表里 等用户来查询的时候 直接 select *from 就好了
然后后台在不定期看数据时效性来自动跟新这个表就行了
是不是很无脑

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

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

1.数据修改只能是通过待更新标记再重新同步。
2.但假如你使用 OLAP 数据库，比如 ClickHouse ，就像我之前说过的要注意是否有时不时的数据更新操作，如果有则不推荐。因为更新操作会引起索引重建，严重影响性能。非要更新的话也得是批量更新，数据更新及时性会受影响。我们之前的业务比如广告埋点，发送短信等这些数据插入/查询的业务每天几个亿数据，做数据分析连表查询性能很高，美滋滋。

可行. 但 ck 没有 join reorder, 写 join sql 的时候得是大表在左, 小表在右, 否则性能比较差. Doris 优化器做的还可以, 也可以考虑 Doris

没专职的 DBA ，难为 OP 了。

从最简单的做起：
1 、升级服务器配置，加内存，提升数据块缓冲区大小；不知 MSSQL 这个怎么做。Oracle 这样做有奇效。硬盘搞 SSD ，阿里云用本地 SSD ，IOPS 提升不小。
2 、分析慢 SQL ，慢 SQL 一般是多表 JOIN ，查询没利用到索引，导致全表扫描。先识别出来，加索引来提升效率，有奇效。
3 、分表，计算结果缓存，读写分离。
优化顺序 ：应用 -- 》数据库 --》系统架构

我的认知就这么多了

大 SQL ，见过几千行的 SQL ，真佩服那哥们能写得出来，反正我是不行。

后来重写，几十行搞定，运行效率还高。

没人没钱就让哥们你来解决？ 可以准备跑路了。

＃2 ，有个疑问，按照你们领导“先写 redis ，再落地数据库”的想法，怎么知道 redis 里的哪些数据需要落地数据库？通过读取 AOF 日志文件吗

ck 不用考虑了，应用场景很狭窄，尤其是带条件多字段索引根本没法用。

是 尤其是带条件多字段”查询“根本没法用

这是挖坑的方案

不建议 ES：

1. ES 需要同步。如果数据源修改增加了字段，ES 还得折腾一番

2. ES 运维成本相当高

   以我公司的场景，分析类查询从 RDS-mysql 迁移到 ADB 的提升也没多少……

   ＃62 ，@lvlongxiang199 ＃63 明白了，谢谢大佬们
   ＃64 谢谢，数据库这块我也不精通，优化 SQL 什么的没问题，再深入点就两眼一抹黑了，应用和架构层面我能做的都做了，现在就差数据库
   ＃66 是的，Redis 这方案已经否了，最多拿 Redis 做个缓存，ES 做不了太复杂的聚合查询，也不适用
   ＃67 原先项目是指定几个接口或者几张表的数据，都走 Redis

目前来看最适合的还是 OLAP 型数据库

ES 还得单独学习它的一套查询语法，没意义。
有钱：加配置；用独立主机（包括下云部署到 IDC ）
有时间：数据库分表、分库；应用拆分适当微服务化；数据库迁移为 PG
pigsty.io/zh/blog/db/7-week-7-db/

加 redis 不太行，改动大工作量大，见效慢，经典的面试问题：缓存和数据库一致性

把 TOP3 or TOP5 的复杂查询针对性优化一下先缓解，然后通过 DTS 到 ck 或者 doris ，建成一个单独的 OLAP 库感觉比较合适（不太适合高并发场景，看你业务）

短期：先加 RDS 配置，解决紧急投诉问题。
长期：还得慢慢把 SQL 、业务逻辑优化了。
不到万不得已不建议引入新的中间件，引入新的环节也是一种不可控和增加成本。

一堆 Join 还是 doris 吧，CH 需要你对各个引擎以及业务数据库具体设计都要有很深的理解

业务瓶颈在读，肯定要从读这侧下手吧，既然读写分离了，就把读的数据导入到适合业务场景的数据库里呗？

据说 doris/starrocks 对 join 支持比较好，建议试一下。这东西都要试了才知道，建议先从简单的开始，AnalyticDB + 弹性扩容，如果不能满足你们需求再看看别的方案。复杂的 SQL 很多时候避免不了全表扫描，唯一解决方案就是用一个弹性的方案

＃72 以我公司那复杂的 sql 体验来看，迁移到 ADB 的提升是巨大的，实测

目前的方案是读从 redis ，低频写的话正常写，高频写的话用消息队列慢慢消费

扯犊子呢，缓存到 redis 碰到大 key 怎么办，为啥不优化 sql

Redis 确实可行，老项目 sql 优化已经十分困难，我做过一个老项目优化就是中间做了一层 redis ，低频操作正常写库，高频查的走 redis 系统性能提升非常明显。

我公司是进销存场景，提升大概 30% 左右吧