今日关键词数据库优化、慢查询、数据归档、中间表、分库分表、分布式缓存、读写分离、CQRS、存储选型、信创大家好我是数据库小学妹 最近在项目里遇到一个问题。线上数据库查询越来越慢加了索引快了一点过两天又慢了。当时我就在想——除了加索引还有没有别的路后来花了两周时间把数据库优化的方案系统梳理了一遍。发现优化这件事思路比手段重要。今天把学到的整理出来分享给同样在踩坑的朋友。先搞清楚数据库为什么会慢慢的本质就三个数据量大表里几千万行全表扫描一次就好几秒查询复杂多表JOIN、子查询嵌套、GROUP BY排序CPU和临时表开销大并发高QPS上千后磁盘I/O和锁争抢成为瓶颈关系型数据库的索引结构基本是B树查找时间复杂度O(log n)。这个是固定的。所以优化空间主要在减少扫描数据量和降低单次查询开销上。四层思考框架优化从顶到底分四层越往下成本越低硬件层加内存、换SSD。花钱多但立竿见影。存储系统层关系型扛不住上NoSQL或者换更适合的数据库。存储结构层分库分表、归档、调整表设计。具体实现层加索引、改写SQL、调整执行计划。原则从最底层开始。索引和SQL优化没空间了再考虑表结构再考虑换存储。一、减少数据量方案一数据归档把历史数据从主表迁走。主表只留近三个月的订单历史数据进归档表。主表数据量从3000万降到200万查询耗时从3秒降到200毫秒。用定时任务定期迁移比如每天凌晨跑一次。注意要分批迁别一次DELETE太多长事务会锁表还撑满undo log。建议每批5000-10000条加SLEEP间隔。MySQL执行DELETE后不释放磁盘空间需要OPTIMIZE TABLE但这个操作会锁表建议在低峰期做。如果空间还够可以先不执行。方案二中间表结果表复杂查询的结果预先算好存起来。报表场景最典型原始数据几十万行按月汇总后只有几百条。季报基于月报汇总年报基于季报汇总。几年的数据都能秒查。粒度越细字段越多灵活性越高可以做二次关联。粒度越粗字段越少适合直接查结果。设计的时候想清楚后续业务会不会在这个基础上再加工会的话就留细粒度。方案三数据序列化存储有些数据不需要按字段检索。比如订单的收货地址JSON打包存一个字段就行。省掉关联表减少数据量。但这方案有局限。序列化后没法按里面的字段WHERE过滤。而且更新时要整个JSON替换单字段更新不了。适合查询需求简单的场景复杂场景慎用。属于临时优化手段不是长久之计。方案四分库分表垂直拆分按业务拆——用户表、订单表、商品表各管各的。减少单表字段数一页能放更多行I/O效率提升。水平拆分把一张大表拆成多张结构相同的表。拆完要解决路由范围路由按时间分表table_2024_01、table_2024_02。简单直观但数据分布可能不均。Hash取模数据均匀分布但不带分区键就得全表扫。映射表额外建一张表记录非分区键和分区键的对应关系。分库分表是最后手段。路由、跨库Join、分布式事务、分页都会变复杂。能用其他方案解决就别碰。二、用空间换性能方案五分布式缓存热点数据放Redis。用Cache-Aside模式先查缓存miss了查数据库查到后回写缓存。命中率高的场景90%以上的请求都走缓存数据库压力直接降一个量级。几个坑要注意缓存击穿缓存失效瞬间大量请求直打数据库。解决加互斥锁SETNX或者缓存空结果设短过期时间。缓存雪崩大批key同时过期请求全部涌入数据库。解决过期时间加随机偏移量错开过期时间。别滥用缓存不是越多越好。动态条件查询的key组合多维护成本高。80%的性能问题由20%的高频查询引起针对这些就够了。不是所有慢查询都适合如果单次查询就要3秒缓存没命中时并发一上来照样穿透。方案六读写分离一主多从部署多个从库分担读压力主库只处理写入。适合读多写少的场景。路由可以用代码实现也可以用中间件。云环境下加从库很方便DBA操作就行。市面上不少关系型数据库都支持读写分离配合数据同步工具可以灵活搭建主从拓扑。但数据是完整冗余的硬件成本高。从库太多会给主库同步带来压力。另外主从有延迟写完立刻读从库可能读到旧数据。对一致性要求高的场景关键读操作还是要走主库。三、选对存储系统方案七CQRS模式写入用关系型数据库保证ACID查询用NoSQL做高性能读取。两边各取所长。选CQRS的写入端要综合考虑并发量、一致性需求和运维成本。国产的KES在高并发OLTP场景表现稳定Oracle兼容性也不错从Oracle迁移过来代码改动量可控。难点在数据同步。两种方式推CDC/领域事件数据变更时主动推送到查询端实时性高。CDC从数据库底层抓变更日志适合老项目不好改代码的场景。领域事件从业务层发消息适合服务化项目代码可读性好。拉轮询定时查数据库有没有新数据。实现简单但有延迟实时性要求高的场景不适合。方案八替换存储系统根据业务特点选最合适的存储。全文搜索用倒排索引引擎比关系型数据库的LIKE全表扫描快几个量级。键值缓存用内存数据库Hash结构O(1)查找。图关系查询用图数据库。不同存储系统直接决定了查找算法和数据结构选对了事半功倍。特别是涉及信创等场景数据库的自主可控能力也要纳入考量。像KES在Oracle兼容性方面做得不错从Oracle迁移过来代码改动量可控可以作为替换存储时的选项之一。替换时加一个中间版本。做好全量增量数据同步加上业务开关。验证新旧存储数据一致后再正式切换。出问题随时回退。千万别一刀切平滑过渡才安全。避坑清单先看执行计划再动手别上来就加索引看执行计划找到真正的瓶颈分库分表是最后手段归档、中间表、缓存的成本低得多缓存不是万能药一致性维护成本高滥用会适得其反统计信息要保持更新很多看似复杂的性能问题更新统计信息就解决了数据同步必然有延迟用了一主多从、缓存、CQRS就要接受一定的不一致没有银弹每个方案都有适用场景结合业务选最合适的我是数据库小学妹咱们下篇见
数据库性能优化怎么做？8个实战方案帮你搞定90%的慢查询
发布时间：2026/6/13 6:08:46
今日关键词数据库优化、慢查询、数据归档、中间表、分库分表、分布式缓存、读写分离、CQRS、存储选型、信创大家好我是数据库小学妹 最近在项目里遇到一个问题。线上数据库查询越来越慢加了索引快了一点过两天又慢了。当时我就在想——除了加索引还有没有别的路后来花了两周时间把数据库优化的方案系统梳理了一遍。发现优化这件事思路比手段重要。今天把学到的整理出来分享给同样在踩坑的朋友。先搞清楚数据库为什么会慢慢的本质就三个数据量大表里几千万行全表扫描一次就好几秒查询复杂多表JOIN、子查询嵌套、GROUP BY排序CPU和临时表开销大并发高QPS上千后磁盘I/O和锁争抢成为瓶颈关系型数据库的索引结构基本是B树查找时间复杂度O(log n)。这个是固定的。所以优化空间主要在减少扫描数据量和降低单次查询开销上。四层思考框架优化从顶到底分四层越往下成本越低硬件层加内存、换SSD。花钱多但立竿见影。存储系统层关系型扛不住上NoSQL或者换更适合的数据库。存储结构层分库分表、归档、调整表设计。具体实现层加索引、改写SQL、调整执行计划。原则从最底层开始。索引和SQL优化没空间了再考虑表结构再考虑换存储。一、减少数据量方案一数据归档把历史数据从主表迁走。主表只留近三个月的订单历史数据进归档表。主表数据量从3000万降到200万查询耗时从3秒降到200毫秒。用定时任务定期迁移比如每天凌晨跑一次。注意要分批迁别一次DELETE太多长事务会锁表还撑满undo log。建议每批5000-10000条加SLEEP间隔。MySQL执行DELETE后不释放磁盘空间需要OPTIMIZE TABLE但这个操作会锁表建议在低峰期做。如果空间还够可以先不执行。方案二中间表结果表复杂查询的结果预先算好存起来。报表场景最典型原始数据几十万行按月汇总后只有几百条。季报基于月报汇总年报基于季报汇总。几年的数据都能秒查。粒度越细字段越多灵活性越高可以做二次关联。粒度越粗字段越少适合直接查结果。设计的时候想清楚后续业务会不会在这个基础上再加工会的话就留细粒度。方案三数据序列化存储有些数据不需要按字段检索。比如订单的收货地址JSON打包存一个字段就行。省掉关联表减少数据量。但这方案有局限。序列化后没法按里面的字段WHERE过滤。而且更新时要整个JSON替换单字段更新不了。适合查询需求简单的场景复杂场景慎用。属于临时优化手段不是长久之计。方案四分库分表垂直拆分按业务拆——用户表、订单表、商品表各管各的。减少单表字段数一页能放更多行I/O效率提升。水平拆分把一张大表拆成多张结构相同的表。拆完要解决路由范围路由按时间分表table_2024_01、table_2024_02。简单直观但数据分布可能不均。Hash取模数据均匀分布但不带分区键就得全表扫。映射表额外建一张表记录非分区键和分区键的对应关系。分库分表是最后手段。路由、跨库Join、分布式事务、分页都会变复杂。能用其他方案解决就别碰。二、用空间换性能方案五分布式缓存热点数据放Redis。用Cache-Aside模式先查缓存miss了查数据库查到后回写缓存。命中率高的场景90%以上的请求都走缓存数据库压力直接降一个量级。几个坑要注意缓存击穿缓存失效瞬间大量请求直打数据库。解决加互斥锁SETNX或者缓存空结果设短过期时间。缓存雪崩大批key同时过期请求全部涌入数据库。解决过期时间加随机偏移量错开过期时间。别滥用缓存不是越多越好。动态条件查询的key组合多维护成本高。80%的性能问题由20%的高频查询引起针对这些就够了。不是所有慢查询都适合如果单次查询就要3秒缓存没命中时并发一上来照样穿透。方案六读写分离一主多从部署多个从库分担读压力主库只处理写入。适合读多写少的场景。路由可以用代码实现也可以用中间件。云环境下加从库很方便DBA操作就行。市面上不少关系型数据库都支持读写分离配合数据同步工具可以灵活搭建主从拓扑。但数据是完整冗余的硬件成本高。从库太多会给主库同步带来压力。另外主从有延迟写完立刻读从库可能读到旧数据。对一致性要求高的场景关键读操作还是要走主库。三、选对存储系统方案七CQRS模式写入用关系型数据库保证ACID查询用NoSQL做高性能读取。两边各取所长。选CQRS的写入端要综合考虑并发量、一致性需求和运维成本。国产的KES在高并发OLTP场景表现稳定Oracle兼容性也不错从Oracle迁移过来代码改动量可控。难点在数据同步。两种方式推CDC/领域事件数据变更时主动推送到查询端实时性高。CDC从数据库底层抓变更日志适合老项目不好改代码的场景。领域事件从业务层发消息适合服务化项目代码可读性好。拉轮询定时查数据库有没有新数据。实现简单但有延迟实时性要求高的场景不适合。方案八替换存储系统根据业务特点选最合适的存储。全文搜索用倒排索引引擎比关系型数据库的LIKE全表扫描快几个量级。键值缓存用内存数据库Hash结构O(1)查找。图关系查询用图数据库。不同存储系统直接决定了查找算法和数据结构选对了事半功倍。特别是涉及信创等场景数据库的自主可控能力也要纳入考量。像KES在Oracle兼容性方面做得不错从Oracle迁移过来代码改动量可控可以作为替换存储时的选项之一。替换时加一个中间版本。做好全量增量数据同步加上业务开关。验证新旧存储数据一致后再正式切换。出问题随时回退。千万别一刀切平滑过渡才安全。避坑清单先看执行计划再动手别上来就加索引看执行计划找到真正的瓶颈分库分表是最后手段归档、中间表、缓存的成本低得多缓存不是万能药一致性维护成本高滥用会适得其反统计信息要保持更新很多看似复杂的性能问题更新统计信息就解决了数据同步必然有延迟用了一主多从、缓存、CQRS就要接受一定的不一致没有银弹每个方案都有适用场景结合业务选最合适的我是数据库小学妹咱们下篇见
的演进与通信机制)
