我是【会点代码的大叔】，每天为你分享程序员干货，关注并私信我数字“1”，送你一份程序员大礼包。
MySQL 数据库某张表近千万的数据，CRUD比较慢，如何优化？
说实话，这个数据量级， MySQL 单库单表支撑起来完全没有问题的，所以首先还是考虑数据库本身的优化。
从上图可以看到，数据库优化通常可以通过以上几点来实现：
对于开发人员来说，我们需要把注意力放在后面三点：
优化 SQL 语句执行速度的方法有很多，比如：
说完了 MySQL 本身的优化，如果数据量进一步增大的话，我们还有什么优化的方案呢？
主库用于写，从库用于读，将读写分散在不同的数据库上，利用多台机器的资源，来提高数据库的可用性和性能。
如果数据持续增多，超过了单台 MySQL 的支撑上限，那么只能用【分库分表】这一招了；我们可以采用一定的路由规则，将数据保存到不同的数据库中。
当然，如果不是“迫不得已”，我是不太建议分库分表的，因为这样极大地增加了系统的复杂程度，并且会带来更多的问题需要开发人员解决。
以上就是常用的 MySQL 优化方案，如果是千万级数据量，优化 MySQL 本身即可。
评论0
加载中...
MySQL 数据库某张表近千万的数据，CRUD比较慢，如何优化？最常见的是线程池优化、索引优化、缓存优化、读写分离、数据库拆分等，上述4种优化可以从不同角度来优化我们的数据库操作，其中的可操作性性要看团队的技术能力和应用的维护能力，我就以自己遇到过的应用场景简单谈谈自己的优化流程。
换到新的团队，遇到的第一个棘手问题就是数据库不定时的出现“Cannot get a connection, pool error Timeout waiting for idle object”，经和DBA沟通，其反馈数据库group（数据库量级4kw+）中的查询逻辑很多，qps达1w+，并且慢sql积压，拖垮了数据库。从慢sql和上述查询异常着手，进行千万级的数据库优化。
1. 线程池优化。线上的读线程池16，写线程池池16，考虑到数据查询时获取不到数据库连接，将读线程池调整为32，其优化效果不明显，数据库建立连接的异常仍然存在。
2.索引优化。经和DBA分析相关的慢sql语句，发现其索引都是完备的，也就是说每个查询都可以落到对应的索引逻辑，这点儿我们心里是有数的，毕竟线上正常运行了2年多数据库，当时建库和查询时肯定考虑到了索引的情况。也就是说，在这方面没有优化的余地。
3.缓存优化。经排查，线上的相关操作采用缓存加速，缓存时间1h或24h不等，考虑到数据库瓶颈和更新数据删缓存的逻辑，将缓存时间延长至7天。该优化逻辑上线后，数据库异常有所减弱，但问题仍未解决。偶尔发现，客户端偶尔会请求服务端不存在的数据，引发缓存穿透。而针对该库涉及到的可能存在缓存穿透的逻辑，进行了一系列优化。优化之后，效果特别明显，也就是在线上业务达到一定量级时，要特别注意缓存穿透，这点在业务刚开始时很容易被忽略。
4.读写分离。虽然通过缓存穿透的优化处理，解决了数据库连接异常的问题，但是读写分离仍然值得尝试，读写分离是应对读多写少业务的一大利器，一主多从的读写分离模式被引入弹性数据库体系，让我们在特殊节点的业务保障更有信心。
5.数据库拆分，也就是分库分表。业务发展到一定程度，分库分表是优化的必经之路，也是我们团队一项很重要的优化业务，但限于业务场景、分库分表规则、多维度查询、团队研发资源等，目前正在规划中。
综上所述，通过优化缓存穿透和读写分离解决了我们线上业务的数据库性能问题，可操作性强，风险相对降低。
作者：夕阳雨晴，欢迎关注我的头条号：偶尔美文，主流Java，为你讲述不一样的码农生活。
评论0
加载中...0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答
