MySQL单表数据不高出多少好?

打印 上一主题 下一主题

主题 1871|帖子 1871|积分 5613

马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。

您需要 登录 才可以下载或查看,没有账号?立即注册

x
一样平常发起范围


  • 通例应用场景:单表数据量发起控制在 500万-1000万行 以内
  • 高性能要求场景:最好控制在 100万-300万行 以内
  • 超大表:高出 2000万行 性能会明显下降,需要特别优化
数字怎么来的?

1. B+树索引的深度限制

MySQL InnoDB 的索引采用 B+树结构,其查询服从与树的高度(深度)直接相关。


  • 假设

    • InnoDB 默认页巨细 = 16KB
    • 主键是 BIGINT(8字节),加上指针(6字节),每行索引约占用 14字节
    • 单页可存储的索引条目数 = 16KB / 14B ≈ 1170 条

  • 索引深度计算

    • 2层B+树:1170 × 1170 ≈ 137万行
    • 3层B+树:1170³ ≈ 16亿行
    • 实际场景:3层B+树时,范围查询或非主键索引可能需要更多磁盘I/O,性能开始下降。
      ⇒ 因此,单表发起控制在万万级以内,避免树深度高出3层。

2. 内存与磁盘I/O的平衡



  • 缓冲池(Buffer Pool):InnoDB 依靠内存缓冲池缓存热点数据。

    • 若单表数据量远大于缓冲池(如 100GB 表 + 8GB 内存),频繁的磁盘换入换出会导致性能骤降。
    • 经验值:单表数据文件巨细 ≤ 缓冲池的 50%~60%(如 8GB 内存,表发起 ≤ 4~5GB)。
    • 按单行 1KB 估算:5GB / 1KB ≈ 500万行。

3. 实际业务场景的验证



  • 高频写入场景

    • 单表高出 1000万行后,索引维护成本(B+树分裂、锁竞争)显著增加,TPS 下降。

  • 复杂查询场景

    • 多条件联合查询、JOIN 操作在大表上相应时间非线性增长(如 100万行时 10ms,1000万行时 100ms+)。

4. MySQL 官方和社区的共识



  • MySQL 手册:虽未明确限制单表行数,但发起对大数据量表利用分区(Partitioning)。
  • 阿里云/RDS 等厂商:公开发起单表不高出 2000万~5000万行(基于SSD和高配内存优化后的值)。
  • Percona 等优化团队:推荐单表 ≤ 1000万行,以平衡运维和性能。

表上亿的数据都不慢?

1. 硬件和存储的升级



  • SSD/NVMe磁盘:相比传统机械硬盘,随机I/O性能提升百倍,极大缓解大数据量下的磁盘瓶颈。
  • 大内存服务器:缓冲池(Buffer Pool)可缓存整个表的热点数据(如512GB内存缓存100GB的表)。
  • 分布式存储:云数据库(如AWS Aurora、阿里云PolarDB)通过存储计算分离和分布式文件系统优化大表访问。
2. 表计划优化



  • 精准的索引策略

    • 只对高频查询字段建索引,避免冗余索引(淘汰写入开销)。
    • 利用覆盖索引(Covering Index)避免回表,例如:SELECT id,name FROM user WHERE age=30,联合索引(age,id,name)可直接返回数据。

  • 字段精简

    • 避免TEXT/BLOB大字段,拆分为关联子表。
    • 利用TINYINT、ENUM等小类型替换VARCHAR。

  • 分区表(Partitioning)

    • 按时间/ID范围分区,查询时只扫描特定分区(如PARTITION BY RANGE (YEAR(create_time)))

3. 查询模式适配



  • 点查询(Point Query)为主

    • 例如SELECT * FROM user WHERE id=123456,通过主键B+树3次I/O即可定位(纵然表有10亿行)。

  • 避免全表扫描

    • 禁止SELECT *、LIKE '%xx%'等操作,逼迫走索引。

  • 冷热数据分离

    • 高频访问近期数据,历史数据归档到对象存储(如OSS)。

4. 业务场景的特别性



  • 低并发写入:日志类表固然数据量大,但写入频率低,无锁竞争问题。
  • 读多写少:如电商商品表,通过缓存(Redis)拦截99%的查询,数据库压力极小。
  • 批量操作:数据分析场景答应分钟级延迟,通过异步ETL处理。
5. 数据库调优参数



  • 调解InnoDB缓冲池巨细:innodb_buffer_pool_size = 64G(占用70%内存)。
  • 优化刷盘策略:innodb_io_capacity=2000(SSD实用)。
  • 利用并行查询:MySQL 8.0+的parallel read特性。
典型案例对比

场景优化手段效果电商订单表(5亿行)按user_id分库分表 + Redis缓存用户查询本身的订单仅需2msIoT装备日志(20亿行)按时间分区 + 压缩存储 + 列式归档查询最近7天数据相应<100ms社交网络用户表(10亿行)主键UUID改为Snowflake ID + 二级索引优化写入TPS提升10倍
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。
回复

使用道具 举报

0 个回复

倒序浏览

快速回复

您需要登录后才可以回帖 登录 or 立即注册

本版积分规则

温锦文欧普厨电及净水器总代理

论坛元老
这个人很懒什么都没写!
快速回复 返回顶部 返回列表