mysql单表体积和一个库设计多少张表为妥

这篇文章来自于看博客园一个园友的分享经历,原文:http://www.cnblogs.com/qqloving/p/3427138.html

 

他不清楚mysql一个库里面分多少张表合适,他一个库分了8000张表。于是我看了,忍不住作答。

 

于是以个人随笔的形式给自己做知识备忘吧。

 

1、单表体积多大的时候需要分表

 

曾经看过一个博客,分析到什么情况下需要分表。

单表形式访问(也就是对这个表的访问不涉及到join联合查询):单个表的体积大于2g的时候。或者说,单个表的行数达到一千万的时候。

两表jion:表的体积大于2G或行数大于500W。

 

在赶集网石展提到的分享中,纯int行不能超过1000万行,含char类型的字段不能超过500万行。与曾经看过文章提到的1000万和500万很相似。难道这是一个瓶颈值吗?

 

2、单个库控制多少张表为妥

听过赶集网的一个dba的分享视频。他从中提到,mysql的单库表数量不要超过300-400张表。这个我也没试过。不过我想应该是他经验之谈吧。

为什么一个库不能很多张表。我的理解是,mysql一个数据库就是磁盘上一个文件夹。那么里面一张表就需要一个文件记录(像myisam类型的是需要三个文件分别记录表结构,记录索引、记录表数据)。
分8000张表,假设是myisam,则需要8000*3个文件。
操作系统对一个目录有文件数限制,当文件数量太多的时候,查找文件的速度就会慢,所以我们经常见到的上传的图片不会全部放到一个文件夹,一般是按照年月日来生成文件夹。

当然,网友提到表的是innodb类型。
innodb类型有两种方式存储数据:共享表和独享表
独享,Innodb_file_per_table,每个表的数据都对应存储在一个文件中
共享,一个库下面所有的innodb类型表数据都存储在一个文件中。
mysql数据全部放到一个文件中去了,当数据量超过一定额度,又会新生成一个数据文件来存储。

 

 

 

时间: 2024-10-03 23:21:15

mysql单表体积和一个库设计多少张表为妥的相关文章

MySQL单表多关键字模糊查询的实现方法_Mysql

在最近的一个项目需要实现在MySQL单表多关键字模糊查询,但这数个关键字并不一定都存在于某个字段.例如现有table表,其中有title,tag,description三个字段,分别记录一条资料的标题,标签和介绍.然后根据用户输入的查询请求,将输入的字串通过空格分割为多个关键字,再在这三个字段中查询包含这些关键字的记录. 可目前遇到的问题是,这些关键字是可能存在于三个字段中的任意一个或者多个,但又要求三个字段必须包含所有的关键词.如果分别对每个字段进行模糊匹配,是没法实现所需的要求,由此想到两种

mysql单表多timestamp报错#1293 - Incorrect table definition;

mysql单表多timestamp报错#1293 - Incorrect table definition; there can be only one TIMESTAMP column with C解决 一个表中出现多个timestamp并设置其中一个为current_timestamp的时候经常会遇到 #1293 - Incorrect table definition; there can be only oneTIMESTAMP column with CURRENT_TIMESTAMP

mysql修改表、字段、库的字符集

mysql修改表.字段.库的字符集 修改数据库字符集: ALTER DATABASE db_name DEFAULT CHARACTER SET character_name [COLLATE ...]; 把表默认的字符集和所有字符列(CHAR,VARCHAR,TEXT)改为新的字符集: ALTER TABLE test CONVERT TO CHARACTER SET character_name [COLLATE ...] 如:ALTER TABLE test CONVERT TO CHAR

MySQL单表ibd文件恢复方法详解_Mysql

前言: 随着innodb的普及,innobackup也成为了主流备份方式.物理备份对于新建slave,全库恢复的需求都能从容应对. 但当面临单表数据误删,或者单表误drop的情况,如果使用物理全备进行恢复呢? 下文将进行详细分析. 恢复过程中需要用到的工具,percona data recover tool : https://launchpad.net/percona-innodb-recovery-tool 情况一:误删部分数据,需要用最近一次备份覆盖 来自同一台机器的ibd恢复覆盖,且备份

MySQL单表百万数据记录分页性能优化技巧_Mysql

测试环境: 先让我们熟悉下基本的sql语句,来查看下我们将要测试表的基本信息 use infomation_schema SELECT * FROM TABLES WHERE TABLE_SCHEMA = 'dbname' AND TABLE_NAME = 'product' 查询结果: 从上图中我们可以看到表的基本信息: 表行数:866633 平均每行的数据长度:5133字节 单表大小:4448700632字节 关于行和表大小的单位都是字节,我们经过计算可以知道 平均行长度:大约5k 单表总大

MySQL单表模拟锁的几个场景

  在MySQL中对于并发,锁问题总是会有很多值得讨论的地方,但是通常来说,要模拟这些锁或者一些锁的问题需要花点功夫,比如创建多个表,创建大量的数据,然后像调试钟表的秒针一样,让问题刚好复现在哪个时间点上.如果换一个角度,单表来模拟这类而是可以吗,其实是可行的.    今天简单通过单表的测试模拟死锁,事务中的隐式提交(其实可以理解是个bug),间隙锁. 初始化数据 首先的准备工作就是初始化数据,我们创建一个表test,事务隔离级别为默认的RR. 建表语句: create table test(

mysql单表多timestamp的current_timestamp设置问题

一个表中出现多个timestamp并设置其中一个为current_timestamp的时候经常会遇到 1293 - Incorrect table definition; there can be only one TIMESTAMP column with CURRENT_TIMESTAMP in DEFAULT or ON UPDATE clause 原因是当你给一个timestamp设置为on update current_timestamp的时候,其他的timestamp字段需要显式设定

【重磅推荐】MySQL大表优化方案(最全面)

当MySQL单表记录数过大时,增删改查性能都会急剧下降,可以参考以下步骤来优化: 单表优化 除非单表数据未来会一直不断上涨,否则不要一开始就考虑拆分,拆分会带来逻辑.部署.运维的各种复杂度,一般以整型值为主的表在千万级以下,字符串为主的表在五百万以下是没有太大问题的.而事实上很多时候MySQL单表的性能依然有不少优化空间,甚至能正常支撑千万级以上的数据量: 字段 尽量使用TINYINT.SMALLINT.MEDIUM_INT作为整数类型而非INT,如果非负则加上UNSIGNED VARCHAR的

MySQL大表优化方案

MySQL大表优化方案 mysql   manong 2016年08月03日发布 当MySQL单表记录数过大时,增删改查性能都会急剧下降,可以参考以下步骤来优化: 单表优化 除非单表数据未来会一直不断上涨,否则不要一开始就考虑拆分,拆分会带来逻辑.部署.运维的各种复杂度,一般以整型值为主的表在千万级以下,字符串为主的表在五百万以下是没有太大问题的.而事实上很多时候MySQL单表的性能依然有不少优化空间,甚至能正常支撑千万级以上的数据量: 字段 尽量使用TINYINT.SMALLINT.MEDIU