1、时代背景与ORM选择 1.1 互联网时代的数据挑战 业务量暴涨，数据也跟着狂飙。百万级数据在几年前还算大，如今动不动就上亿。与此同时，微服务拆分得越来越细，数据访问层变得又厚又复杂。大家一边要追新

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

虽然这篇文章会分析MySQL的源码，但是我保证，只要你认认真真的读完，一定能从本质上彻底掌握count(*)、count(1)、count(id)、count(name)之间的区别。 首先，count

前言 对于后端开发同学来说，访问数据库，是代码中必不可少的一个环节。 系统中收集到用户的核心数据，为了安全性，我们一般会存储到数据库，比如：mysql，oracle等。 后端开发的日常工作，需要不断的

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

本文已参与好文召集令活动，点击查看：后端、大前端双赛道投稿，2万元奖池等你挑战！」 数据库命名规范 采用小写字母、数字（通常不需要）和下划线组成。禁止使用’-’，命名简洁、含义明确。 表命名 根据业务

前言 作为后端开发，我们经常需要设计数据库表。整理了21个设计MySQL表的经验准则，分享给大家，希望大家看完会有帮助。 1. 命名规范 数据库表名、字段名、索引名等都需要命名规范，可读性高(一般要求

背景 在上一篇《浅谈mysql数据可靠性》的文章中，简单地聊了一下锁在实现数据可靠性中的具体作用，这篇文章我想继续来聊聊mysql的锁是怎么加上的，为啥想聊这个呢？主要是因为业务中我们或多或少都会使用

面试官：麻烦你好好看看这篇文章，再告诉我，每张表到底能存多少数据？ 实际情况下，每张表由于自身的字段不同、字段所占用的空间不同等原因，它们在最佳性能下可以存放的数据量也就不同，需要手动计算才行。