mysql数据库可以有多大(mysql数据库能存多大数据)

MySQL322限制的表大小为4GB。由于在MySQL323中使用了MyISAM存储引擎，最大表尺寸增加到了65536TB（2567_1字节）。由于允许的表尺寸更大，MySQL数据库的最大有效表尺寸通常是由 *** 作系统对文件大小的限制决定的，而不是由MySQL内部限制决定的。

InnoDB存储引擎将InnoDB表保存在一个表空间内，该表空间可由数个文件创建。这样，表的大小就能超过单独文件的最大容量。表空间可包括原始磁盘分区，从而使得很大的表成为可能。表空间的最大容量为64TB。

扩展资料

据DVB团队以及Cmshelp团队做CMS系统评测时的结果来看，MySQL单表大约在2千万条记录（4G）下能够良好运行，经过数据库的优化后5千万条记录（10G）下运行良好。

这对于MySQL是不公平的，那些CMS厂商非但没有把内核做好反而还在添加很多花哨的功能，最终导致其产品自身负载过低。

他们并没有针对自身负载效果作出相应的数据库优化方案及标准，而是继续保留着复杂的结构造成对MySQL的资源无休止的浪费，最终导致了其负载上的缺陷。

于是他们便充分发挥中国人的传统优势——变通：避重就轻的采用了所谓的分表式存储，虽然在一定程度上缓解了自身负载的缺陷，但是导致了网站后期维护以及资源上的浪费。

用一个不恰当的比喻来形容，MySQL中的的表就像一块地，单表就相当于利用这块地盖高层建筑充分利用达到高人员负载，但分表就相当于用这块地盖了一间平房。

如果为了达到高人员负载的话那就需要另开地皮达到目的，但是我们要思考，是地不够，还是他的能力不够，如此做法让人感到资源的浪费以及规划的严重缺陷。

修改数据库导入文件大小限制方法步骤：

1、下载个Navicat for MySQL并安装，安装后运行navicat，界面如下图：

2、然后连接到数据库，如下图，点击“文件”下方的“链接”。分别输入链接名、主机名或ip、用户名和密码。点击确定。

3、接下来连接yatai，然后选中需要链接的数据库，点击右键，选择打开数据库。然后再选中需要链接的数据库并右键，运行SQL文件。

4、打开运行sql文件对话框，然后点击“文件”右侧的方框，在本地电脑上选择您要导入的数据库，点击开始。

5、数据库导入开始，进度完成就可以了。

dmp文件大小数据文件大小

dmp文件和数据文件都是用于存储数据的文件，但是它们的含义和用途不同，因此它们的大小也可能有所不同。

dmp文件是Oracle数据库的备份文件，包含了数据库的完整结构和数据信息，通常用于备份和恢复数据库。dmp文件大小取决于数据库的大小，通常会比数据文件大一些。

数据文件是Oracle数据库中实际存储数据的文件，包含了表空间、数据块和数据记录等信息。数据文件大小取决于数据库中存储的数据量以及文件系统的限制，一般来说，数据文件的大小应该与数据库的大小相当。

因此，dmp文件和数据文件的大小都取决于数据库的大小和存储的数据量，但是它们的含义和用途不同，需要根据具体情况来选择使用哪种文件。

您好，很高兴为您解答。

下面有两个SQL语句可以达到在SQL Server 2005/2008压缩指定数据库文件和日志的大小的效果：

1、DBCC SHRINKDATABASE (Transact-SQL)

收缩指定数据库中的数据文件和日志文件的大小。

语法

DBCC SHRINKDATABASE

( 'database_name' | database_id | 0

[ ,target_percent ]

[ , { NOTRUNCATE | TRUNCATEONLY } ]

)

[ WITH NO_INFOMSGS ]

参数

'database_name' | database_id | 0 要收缩的数据库的名称或 ID。如果指定 0，则使用当前数据库。

target_percent 数据库收缩后的数据库文件中所需的剩余可用空间百分比。

NOTRUNCATE 通过将已分配的页从文件末尾移动到文件前面的未分配页来压缩数据文件中的数据。target_percent 是可选参数。 文件末尾的可用空间不会返回给 *** 作系统，文件的物理大小也不会更改。因此，指定 NOTRUNCATE 时，数据库看起来未收缩。 NOTRUNCATE 只适用于数据文件。日志文件不受影响。

TRUNCATEONLY 将文件末尾的所有可用空间释放给 *** 作系统，但不在文件内部执行任何页移动。数据文件只收缩到最近分配的区。如果与 TRUNCATEONLY 一起指定，将忽略 target_percent。 TRUNCATEONLY 只适用于数据文件。日志文件不受影响。

WITH NO_INFOMSGS 取消严重级别从 0 到 10 的所有信息性消息。

结果集

列名 说明

DbId 数据库引擎试图收缩的文件的数据库标识号。

FileId 数据库引擎尝试收缩的文件的文件标识号。

CurrentSize 文件当前占用的 8 KB 页数。

MinimumSize 文件最低可以占用的 8 KB 页数。这与文件的最小大小或最初创建时的大小相对应。

UsedPages 文件当前使用的 8 KB 页数。

EstimatedPages 数据库引擎估计文件能够收缩到的 8 KB 页数。

备注

若要收缩特定数据库的所有数据和日志文件，请执行 DBCC SHRINKDATABASE 命令。若要一次收缩一个特定数据库中的一个数据或日志文件，请执行 DBCC SHRINKFILE 命令。

若要查看数据库中当前的可用（未分配）空间量，请运行 sp_spaceused。

可在进程中的任一点停止 DBCC SHRINKDATABASE *** 作，任何已完成的工作都将保留。

收缩后的数据库不能小于数据库的最小大小。最小大小是在数据库最初创建时指定的大小，或是使用文件大小更改 *** 作（如 DBCC SHIRNKFILE 或 ALTER DATABASE）显式设置的最后大小。例如，如果数据库最初创建时的大小为 10 MB，后来增长到 100 MB，则该数据库最小只能收缩到 10 MB，即使已经删除数据库的所有数据也是如此。

运行 DBCC SHRINKDATABASE 而不指定 NOTRUNCATE 选项或 TRUNCATEONLY 选项等价于带 NOTRUNCATE 运行 DBCC SHRINKDATABASE *** 作，然后再带 TRUNCATEONLY 运行 DBCC SHRINKDATABASE *** 作。

要收缩的数据库不必在单用户模式下；其他的用户仍可以在数据库收缩时对其进行工作。这也包括系统数据库。

不能在备份数据库时收缩数据库。反之，也不能在数据库执行收缩 *** 作时备份数据库。

DBCC SHRINKDATABASE 的工作原理

DBCC SHRINKDATABASE 以每个文件为单位对数据文件进行收缩。然而，DBCC SHRINKDATABASE 在对日志文件进行收缩时，它将视为所有的日志文件都存在于一个连续的日志池中。文件始终从末尾开始收缩。

假设名为 mydb 的数据库有一个数据文件和两个日志文件。数据文件和日志文件分别是 10 MB，并且数据文件包含 6 MB 数据。

Microsoft SQL Server 2005 数据库引擎对每个文件计算一个目标大小。这就是文件将要收缩到的大小。将 target_percent 与 DBCC SHRINKDATABASE 一起指定时，数据库引擎计算的目标大小是收缩后文件中的 target_percent 可用空间大小。例如，如果在收缩 mydb 时将 target_percent 指定为 25，则数据库引擎将此文件的目标大小计算为 8 MB（6 MB 数据加上 2 MB 可用空间）。因此，数据库引擎将任何数据从数据文件的后 2 MB 中移动到数据文件前 8 MB 的可用空间中，然后对该文件进行收缩。

假设 mydb 的数据文件包含 7 MB 的数据。将 target_percent 指定为 30，以允许将此数据文件收缩到可用空间为 30％。但是，将 target_percent 指定为 40 却不会收缩数据文件，因为数据库引擎收缩文件的目标大小不能小于数据当前占用空间大小。您还可以用另一种方法来考虑此问题：所要求的 40％ 可用空间加上整个数据文件大小的 70％（10 MB 中的 7 MB），超过了 100％。因为所要求的可用百分比加上数据文件占用的当前百分比大于 100%（多出 10%），所以任何大于 30 的 target_size 都不会收缩此数据文件。

对于日志文件，数据库引擎使用 target_percent 来计算整个日志的目标大小；因此，target_percent 是收缩 *** 作后日志中的可用空间大小。之后，整个日志的目标大小转换为每个日志文件的目标大小。

DBCC SHRINKDATABASE 尝试立即将每个物理日志文件收缩到其目标大小。如果虚拟日志中的所有逻辑日志部分都没有超出日志文件的目标大小，则该文件将成功截断，DBCC SHRINKDATABASE 完成且不显示任何消息。但是，如果部分逻辑日志位于超出目标大小的虚拟日志中，则数据库引擎将释放尽可能多的空间，并发出一条信息性消息。该消息说明需要执行哪些 *** 作来将逻辑日志移出位于文件末尾的虚拟日志。执行该 *** 作以后，DBCC SHRINKDATABASE 可用于释放剩余空间。有关详细信息，请参阅收缩事务日志。

因为日志文件只能收缩到虚拟日志文件边界，所以不可能将日志文件收缩到比虚拟日志文件更小（即使现在没有使用该文件）。虚拟日志文件的大小在创建或扩展这些日志文件时由数据库引擎动态选择。有关虚拟日志文件的详细信息，请参阅事务日志物理体系结构。

权限

要求具有 sysadmin 固定服务器角色或 db_owner 固定数据库角色的成员身份。、

示例

A 收缩数据库并指定可用空间的百分比

以下示例将减小 UserDB 用户数据库中数据文件和日志文件的大小，以便在数据库中留出 10% 的可用空间。

DBCC SHRINKDATABASE (UserDB, 10);

GO

B 截断数据库

以下示例使 AdventureWorks 示例数据库中的数据文件收缩到最后分配的区。

DBCC SHRINKDATABASE (AdventureWorks, TRUNCATEONLY);

请参考：>

看，一个最简单的方法，是在 对象资源管理器 →数据库 右键 新建数据库

然后d出下面的窗口 ，选择建立就完了

如果是sql语句的话

应该是这样子滴

create database Accounting --数据库名

on

(name='AccountingName',

filename='F:\Accountingmdf', --地址

size=10mb,

maxsize=50mb,

filegrowth=5mb)

log on(name='AccountingLog',

filename='F:\Accountinglog', --日志文件地址

size=10mb,

maxsize=50mb,

filegrowth=5mb)

参数解释：

on:简单理解为定义存储数据库文件的位置

filename:数据库的逻辑别名

size:数据库初始大小

maxsize:数据库初大容量

filegrowth:数据库每次增加的容量．

log on:简单理解为定义存储数据库日志文件的位置．

Hibernate配置文件中，有一个hibernatehbm2ddlauto选项。

当值为create时，会先删除数据表，然后重新创建。

当值为update时，会更新数据表结构，数据还存在。

也就是说上面两种情况，会按照映射文件中的length来设置。

但是，当值为validate时，就会检查映射文件和数据库表设计，当不一致时，就会抛异常。

顺便说一下，开发人员的习惯是先设计数据库，然后再进行映射。因此，length基本上不用配置。

<property name="" type="" column="" /> 就够用了。

除非，你要先设计Java POJO类，然后由类导出数据库结构，才需要填上length、not-null这些精细控制。但是，这种开发习惯基本上没人用，做个练习还是有价值的。

技术规格

--------------系统技术规格---------------

--每个服务器最多可以允许16个SQLSERVER实例

--每个实例可拥有2147483467个锁

--------------数据库技术规格--------------

--SQLSERVER的数据库大小1048516TB

--每个数据库可拥有的文件组数32767

--每个数据库可拥有的文件组数256

--文件大小(数据文件)32TB---

--文件大小(日志文件)32TB---

--数据库中的对象数2147483647

--标识符的长度128

--------------表技术规格-------------------

--每个数据库中可拥有的表数受限于数据库中的对象数

--每个表可拥有的行数受限于可用的存储容量

--每个表的主键约束数1

--每个表的外键约束数253

--每个表的引用数253

--每个表的触发器数受限于数据库中的对象数

--每个表的簇索引数1

--每个表的非簇索引数249

--每个表的唯一约束249非簇的,1成簇的

--------------列技术规格-------------------

--每个索引可包含的列数16

--每个主键可包含的列数16

--每个外键可包含的列数16

--每个表的列数1024

--索引键的大小900字节

--每个character或binary列的字节数8000

--每个text,ntext或image列的字节数2GB-2

--每行的字节数8060

--每个索引的字节数900

--每个主键的字节数900

--每个外键的字节数900

--------------SQL技术规格-------------------

--批处理大小65536乘以网络包大小

--每个SELECT语句可处理的表数256

--存储过程源文件的字节数小于批处理大小或250MB

--每个存储过程的参数数目1024

--嵌套的子查询数32

--嵌套的触发器层数32

--每个SELECT语句可处理的列数4096

--每个INSERT语句可处理的列数1024

以上就是关于mysql数据库可以有多大(mysql数据库能存多大数据)全部的内容，包括:mysql数据库可以有多大(mysql数据库能存多大数据)、wdcp系统中数据库导入大于20M的SQL文件时，怎么修改限制、dmp文件大小数据文件大小等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！