• 暂时停更一段时间!
  • 近期网站将陆续进行前端页面改造!
  • 招募网站编辑,联系站长!

MySQL大表优化策略

文章目录[隐藏]

MySQL 单表记录数过大时,数据库的 CRUD 性能会下降,需要如下的一些优化措施 。

1 )限定数据的范围

对于大数据茸的数据表,全表扫描肯定是不可接受的 。 务必禁止不带任何限制数据范围条件的查询语句存在。 比如, 当用户查询订单历史数据时,可以控制在最近一个月的数据中进行筛选 。

2 )读/写分离

经典的数据库拆分方案主库负责写 ,从库负责读 。

3 )缓存

使用 MySQL 的查询缓存 。
对重量级 、更新少的数据考虑使用应用级别的缓存 。

4 )垂直分区

根据数据库里面数据表的相关性进行拆分。 例如,用户表中既有用户的登录信息又有基本信息,可以拆为两个单独的表做分表,甚至放到单独的库做分库 。 垂直分区的优点在于可以使得行数据变小,在查询时减少读取的 Block 数 , 减少 I/O 次数。 此外, 垂直分区可以简化表的结构 , 易于维护 。

垂直分区的缺点在于主键会出现冗余,需要管理冗余列,并会引起 Join 操作,可以通过在应用层进行 Join 来解决。 此外,垂直分区会让事务管理变得复杂 。

5 )水平分区

水平分区指的是保持数据表结构不变,通过某种策略存储数据分片 。 这样每片数据分散到不同的表或者库中,达到了分布式的目的 。 水平分区可以支撑非常大的数据量 。

如果某个表的数据是时间序列的 ,比如订单 、交易记录等,通常比较适合用时间范围分片 ,因为具有时效性的数据,我们往往更关注其近期的数据,查询条件中一般带有时间字段可以进行过滤 。 可以使用跨度短的时间范围分片活跃数据,跨度长的时间范围分片历史数据 。 此外,订单表包含正在处理和已完成的订单,而正在处理的订单是频繁被访问查 询的,已完成订单则相对来说很少被访问,那么订单状态也可以作为分片的因子,这样可使得频繁访问的正在处理的订单能够保证一个相对小的规模,从而提高处理速度 。 这里分离频繁和不频繁使用的数据也是大表优化的一个原则 。

需要注意的是 ,分表仅仅解决了单一表数据过大的问题,但由于表的数据还是在同一机器上,其实对于提升 MySQL 并发能力没有什么意义 。 所以水平分区最好分库 。

水平分区能够支持非常大的数据量存储,应用端的改造也较少,但分片事务难以解决,跨节点 Join 性能差,逻辑复杂 。

数据库分片主要包括两种分片方案,分别是客户端代理和中间件代理。

客户端代理

分片逻辑在应用端,封装在 jar 包中,通过修改或者封装 JDBC 层来实现。 当当网的 Sharding-JDBC 、阿里的 TDDL 是目前比较为人所知的实现。

中间件代理

在应用和数据中间加了一个代理层 。 分片的逻辑统一维护在中间件服务中 。 间里的 Cobar 、 360 的 Atlas 、网易的 DDB 、开源的 MyCat 和 Kingshard 都是这种架构的实现 。

如非特别必要,不要对数据进行分片,拆分会带来逻辑、部署、运维的各种复杂度 , 一般的数据表在优化得当的情况下支撑千万以下的数据量是没有太大问题的 。 如果实在要分片,尽量选择客户端分片架构,毕竟减少了一次和中间件的网络 1/0 。


丨极客文库, 版权所有丨如未注明 , 均为原创丨
本网站采用知识共享署名-非商业性使用-相同方式共享 3.0 中国大陆许可协议进行授权
转载请注明原文链接:MySQL 大表优化策略
喜欢 (0)
[247507792@qq.com]
分享 (0)
多啦H梦
关于作者:
热爱开源,热爱分享,谢谢大家的资瓷!

邀请您免费 注册账号 登录 即可参与讨论!

(2)个小伙伴在吐槽
  1. 不错
    马云2018-08-19 21:39 Windows 10 | Firefox浏览器 61.0