大家好，欢迎来到 非鱼牛马社，一个热爱技术的全栈开发者。最近在做一个新项目，发现很多同事还在用着最基础的 SQL 语句，写出来的代码又长又难维护。作为一个踩过无数坑的老司机，我觉得是时候分享一些实用的

今年初团队开始推行“服务稳定性问题治理专项”。通过错误日志、慢SQL、接口性能等各项指标的优化，进一步提升系统稳定性与可靠性。在此契机之下，本文将从“慢SQL治理”的角度，通过部分实际案例，分析其原理

千万级数据大概就是MySQL查询的天花板了。这里讨论的情况是在MySQL一张表的数据达到千万级别。表设计很烂，业务统计规则又不允许把sql拆成多个子查询。

Offer 驾到，掘友接招！我正在参与2022春招打卡活动，点击查看活动详情。 简介 ShardingSphere 是一套开源的分布式数据库中间件解决方案组成的生态圈，它由 Sharding-JDBC

在并发一致性控制场景中，我们常常用for update悲观锁来进行一致性的保证，但是如果不了解它的机制，就进行使用，很容易出现事故

随着业务的快速发展，数据库已经有了上亿条记录，数据存储达到了上百G,原有的单库单表设计已经无法支持系统的稳定性以及接口的响应速度了，数据库存在大量慢查询，且需要提供对C端这种大访问量场景提供支持。

先看这段像天书一样的 SQL ,看着就头疼。 这段SQL是干什么用的呢，就是为了计算一个成绩排名，简直大动干戈啊。 那有没有简化的方法呢?

大促备战，最大的隐患项之一就是慢SQL，对于服务平稳运行带来的破坏性最大，也是日常工作中经常带来整个应用抖动的最大隐患，在日常开发中如何避免出现慢SQL，出现了慢SQL应该按照什么思路去解决是我们必须

分页是一个很普通的功能，只要是个后端开发就要写分页，那为什么要分页？从业务上来讲，即使系统返回所有数据，用户绝大多数情况下是不会看后面的数据的。