SQL数据类型_百度百科
特色百科用户权威合作手机百科
收藏 查看&SQL数据类型
Microsoft Jet
SQL 数据类型 由13个基本数据类型组成，它们是由 Microsoft Jet 数据库引擎和几个验证过的有效同义字定义的。常见的有：整形，，双精度，可变长度字符，固定长度字符，长型，等等。外文名Microsoft Jet&常见的有整形语言默认·Char [(n)]
下面的表格列出了主要数据类型。这些同义字在 Microsoft JetSQL 保留字中被识别。
数据类型 存储大小 说明
BINARY 每个占一个字节 任何类型的数据都可存储在这种类型的字段中。不需数据转换（例如，转换到文本数据）。数据输入二进制字段的方式决定了它的输出方式。
BIT 1 个0 和 1 ，以及只包含这两个数值之一的字段。
TINYINT 1 个字节 介于 0 到 255 之间的数。
MONEY 8 个字节 介于 – 922,337,203,685,477.5808 到 922,337,203,685,477.5807 之间的符号整数。
（请参阅 DOUBLE ） 8 个字节 介于 100 到 9999 年的日期或时间数值。
UNIQUEIDENTIFIER 128 个位 用于的唯一识别数字。
REAL 4 个，负数范围是从 –3. 到 –1.，正数从1. 到 3.，和 0。
SMALLINT 2 个字节 介于 –32,768 到 32,767 的短数。
INTEGER 4 个介于 –2,147,483,648 到 2,147,483,647 的长整型数。
DECIMAL 17 个容纳从 1028 - 1到 - 1028 - 1. 的值的精确的数字数据类型。你可以定义精度 (1 - 28) 和 符号 (0 - 定义精度)。缺省精度和符号分别是18和0。
TEXT 每一字符两（参见注意） 从零到最大 2.14 千兆字节。
IMAGE 视实际需要而定 从零到最大 2.14 千兆字节。用于 OLE 对象。
CHARACTER 每一字符两字节（参见注意） 长度从 0 到 255 个字符。
可以用ALTER TABLE 语句修正基数和增量。刚插进表中的行会有自动为基于新种值和增量值的列生成的值。如果新种和增长的值和以前的种值及增量匹配，就会造成复制。如果这个列是主键，复制值生成时可能导致错误。
定义成TEXT也称作MEMO）或CHAR（也称作有具体长度的 TEXT(n)）的字段中的被储存在 Unicode 表示格式。Unicode一律需要两个字节存储每一字符。对于现有的主要包含数据的 Microsoft Jet数据库，这可能意味着被转换成 Microsoft Jet 4.0格式时会增加将近一倍。然而，从前由单群(SBCS)指示的众多字符群的Unicode 表示可以很容易地被压缩成一个单字节。有关的详细信息，参见CREATE TABLE。如果用COMPRESSION属性定义CHAR列，数据存储时会自动被压缩，提取时。
等效的 ANSI SQL 数据类型 Microsoft Jet 数据库引擎 SQL 的保留字数据类型是数据的一种属性，表示数据所表示信息的类型。任何一种都定义了自己的数据类型。当然，不同的程序语言都具有不同的特点，所定义的数据类型的种类和名称都或多或少有些不同。SQLServer 提供了 25 种数据类型：
·Binary [(n)]
·Varbinary [(n)]
·Char [(n)]
·Varchar[(n)]
·Nchar[(n)]
·Nvarchar[(n)]
·Datetime
·Smalldatetime
·Decimal[(p[,s])]
·Numeric[(p[,s])]
·Float[(n)]
·Smallint
·Smallmoney
·Timestamp
·Uniqueidentifier
(1)二进制数据类型
二进制数据包括 Binary、Varbinary 和 Image
Binary 数据类型既可以是固定长度的(Binary),也可以是变长度的。
Binary[(n)] 是 n 位固定的二进制数据。其中，n 的取值范围是从 1 到 8000。其存储窨的大小是 n + 4 个字节。
Varbinary[(n)] 是 n 位变长度的二进制数据。其中，n 的取值范围是从 1 到 8000。其存储窨的大小是 n + 4个字节，不是n 个字节。
在 Image 数据类型中存储的数据是以位串存储的，不是由 SQL Server 解释的，必须由来解释。例如，可以使用BMP、TIEF、GIF 和 JPEG 格式把在 Image 数据类型中。
(2)字符数据类型
数据的类型包括 Char，Varchar 和 Text
数据是由任何字母、符号和数字任意组合而成的数据。
Varchar 是变长数据，其长度不超过 8KB。Char 是定长数据，其长度最多为 8KB。超过 8KB 的ASCII 数据可以使用Text数据类型存储。例如，因为 Html 文档全部都是 ASCII，并且在一般情况下长度超过 8KB，所以这些文档可以 Text 数据类型存储在SQL Server 中。
(3)Unicode 数据类型
Unicode 数据类型包括 Nchar,Nvarchar 和Ntext
在 Microsoft SQL Server 中，传统的非 Unicode 数据类型允许使用由特定定义的。在 SQL Server安装过程中，允许选择一种。使用 Unicode 数据类型，列中可以存储任何由Unicode 标准定义的字符。在 Unicode 标准中，包括了以各种定义的全部字符。使用Unicode数据类型，所占用的窨是使用非Unicode数据类型所占用的窨大小的两倍。
在 SQL Server 中，Unicode 数据以 Nchar、Nvarchar 和 Ntext 数据类型存储。使用这种字符类型的列可以存储多个中的字符。当列的长度变化时，应该使用Nvarchar类型，这时最多可以存储 4000 个。当列的长度固定不变时，应该使用 Nchar类型，同样，这时最多可以存储4000 个字符。当使用 Ntext 数据类型时，该列可以存储多于 4000 个字符。
(4)日期和时间数据类型
日期和时间数据类型包括 Datetime 和 Smalldatetime两种类型
日期和时间数据类型由有效的日期和时间组成。例如，有效的日期和时间数据包括“4/01/98 12:15:00:00:00 PM”和“1:28:29:15:01AM 8/17/98”。前一个数据类型是日期在前，时间在后；后一个数据类型是时间在前，日期在后。在 Microsoft SQL Server中，日期和时间数据类型包括Datetime 和 Smalldatetime 两种类型时，所存储的日期范围是从 1753 年 1 月 1 日开始，到9999 年12 月 31 日结束(每一个值要求 8 个存储)。使用 Smalldatetime 数据类型时，所存储的日期范围是 1900年 1 月 1日 开始，到 2079 年 12 月 31 日结束(每一个值要求 4 个存储字节)。
日期的格式可以设定。设置日期格式的命令如下：
Set DateFormat {format | @format _var|
其中，format | @format_var 是日期的顺序。有效的参数包括 MDY、DMY、YMD、YDM、MYD 和 DYM。在默认情况下，日期格式为MDY。
例如，当执行 Set DateFormat YMD 之后，日期的格式为年 月 日 形式；当执行 Set DateFormat DMY 之后，日期的格式为日 月有年 形式
（5）数字数据类型
数字数据只包含数字。数字数据类型包括正数和负数、小数（浮点数）和整数
整数由正整数和负整数组成，例如 39、25、0-2 和 33967。在 Microsoft SQL Server 中，整数存储的数据类型是 Int，Smallint和 Tinyint。Int 数据类型存储数据的范围大于 Smallint 数据类型存储数据的范围，而 Smallint 据类型存储数据的范围大于Tinyint 数据类型存储数据的范围。使用 Int 数据类型存储数据的范围是从 -2 147 483 648 到 2 147 483 647（每一个值要求4个）。使用 Smallint 数据类型时，存储数据的范围从 -32 768 到 32 767（每一个值要求2个字节）。使用Tinyint 数据类型时，存储数据的范围是从0 到255（每一个值要求1个）。
精确小数数据在 SQL Server 中的数据类型是 Decimal 和 Numeric。这种数据所占的根据该数据的位数后的位数来确定。Decimal 数据类型使用128位来表示值来用作数值计算。
在SQL Server 中，近似小数数据的数据类型是 Float 和 Real。例如，三分之一这个分数记作0.333333，当使用近似数据类型时能准确表示。因此，从系统中检索到的数据可能与存储在该列中数据不完全一样。
（6）货币数据类型
在 Microsoft SQL Server 中，货币数据的数据类型是Money 和 Smallmoney
Money数据类型要求 8 个存储字节，Smallmoney 数据类型要求 4 个存储字节。
（7）特殊数据类型
特殊数据类型包括前面没有提过的数据类型。特殊的数据类型有3种，即 Timestamp、Bit 和 Uniqueidentifier。
Timestamp 用于表示SQL Server 活动的先后顺序，以二进投影的格式表示。Timestamp 数据与插入数据或者日期和时间没有关系。Timestamp 类型的字段是一个基于在数据行被创建或修改时由SQL Server自动填充的值。
Bit 由 1 或者 0 组成。当表示真或者假、ON 或者 OFF 时，使用 Bit 数据类型。例如，询问是否是每一次访问的客户机请求可以存储在这种数据类型的列中。
Uniqueidentifier 由 16的十六进制数字组成，表示一个全局唯一的。当表的记录行要求唯一时，GUID是非常有用。例如，在客户标识号列使用这种数据类型可以区别不同的客户。用户定义的数据类型基于在 Microsoft SQL Server 中提供的数据类型。当几个表中必须存储同一种数据类型时，并且为保证这些列有相同的数据类型、长度和可空性时，可以使用用户定义的数据类型。例如，可定义一种称为 postal_code 的数据类型，它基于 Char 数据类型。
当创建用户定义的数据类型时，必须提供三个数：数据类型的名称、所基于的系统数据类型和数据类型的可空性。
（1）创建用户定义的数据类型
创建用户定义的数据类型可以使用语句。系统sp_addtype 可以来创建用户定义的数据类型。其语法形式如下：
sp_addtype {type},[,system_data_bype][,'null_type']
其中，type 是用户定义的数据类型的名称。system_data_type 是系统提供的数据类型，例如 Decimal、Int、Char 等等。 null_type 表示该数据类型是如何处理的，必须使用单引号引起来，例如'NULL'、'NOT NULL'或者'NONULL'。
Exec sp_addtype ssn,'Varchar(11)','Not Null'
创建一个用户定义的数据类型 ssn，其基于的系统数据类型是变长为11 的，不允许空。
Exec sp_addtype birthday,datetime,'Null'
创建一个用户定义的数据类型 birthday，其基于的系统数据类型是 DateTime，允许空。
Use master
Exec sp_addtype telephone,'varchar(24)','Not Null'
Eexc sp_addtype fax,'varchar(24)','Null'
创建两个数据类型，即 telephone 和 fax
（2）删除用户定义的数据类型
当用户定义的数据类型不需要时，可删除。删除用户定义的数据类型的命令是 sp_droptype {'type'}。
Use master
Exec sp_droptype 'ssn'
注意：当表中的列还正在使用用户定义的数据类型时，或者在其上面还绑定有默认或者规则时，这种用户定义的数据类型不能删除。固定长度为 n 个的且非 Unicode 的数据。n 必须是一个介于 1 和 8,000 之间的数值。大小为 n 个（如varchar(6),当字段为qqq时，数据库实际为也要6个，而不是3个字节，但只允许存储6个字节，一般中文占两个字节）。包含 n 个的固定长度 Unicode 字符数据。n 的值必须介于 1 与 4,000 之间。的存储大小是定义字符个数（n）的两倍。
SQL Server中，varchar和nvarchar如何选择？
varchar在SQL Server中是采用单字节来数据的，nvarchar是使用Unico来存储数据的．中文字符存储到SQL Server中会保存为两个字节（一般采用Unico编码），英文字符保存到数据库中，如果字段的类型为varchar，则只会占用一个字节，而如果字段的类型为nvarchar，则会占用两个字节。
正常情况下，我们使用varchar也可以存储中文，但是如果遇到操作系统是英文操作系统并且对中文字体的支持不全面时，在SQL Server存储中文字符为varchar就会出现乱码(显示为??)。而且正常情况下，主机都会支持中文的环境，所以如果使用varchar来存储数据，在开发阶段是发现不了的。多数情况下，在部署的时候也不会有问题．
但是！如果部署的是英文操作系统，并且不支持中文环境，那问题就出来了。所有的varchar字段在中文的时候都会变成乱码（显示为??）。而且一般情况下你不会知道这是因为你采用了错误的数据类型来存储所造成的，你会试着去装中文字体，试着去设置操作系统的语言环境．．．这些都不能解决问题，唯一能解决问题的是把数据库字段的类型个性为nvarchar（或者nchar）。对项目管理比较熟悉的朋友应该都知道，到部署阶段再来修改数据库是一个很恐怖的事情。
使用nvarchar的另一个非常好处就是在判断串的时候可以不需要考虑中英文两种字符的差别。
当然，使用nvarchar英文字符会增大一倍的。但是在存储代价已经很低廉的情况下，优先考虑兼容性会给你带来更多好处的。
所以在Design的时候应该尽量使用nvarchar来数据。只有在你确保该字段不会保存中文的时候，才采用varchar来存储。
1、CHAR。CHAR存储定长数据很方便，CHAR字段上的索引效率级高，比如定义char(10)，那么不论你存储的数据是否达到了10个，都要占去10个字节的空间。
2、VARCHAR。存储变长数据，但存储效率没有CHAR高。如果一个字段可能的值是不固定长度的，我们只知道它不可能超过10个，把它定义为 VARCHAR(10)是最合算的。VARCHAR类型的实际长度是它的值的实际长度从空间上考虑，用varchar合适；从效率上考虑，用char合适，关键是根据实际情况找到权衡点。
3、TEXT。text存储可变长度的非Unicode数据，最大长度为2^31-1(2,147,483,647)个字符。
4、NCHAR、NVARCHAR、NTEXT。这三种从名字上看比前面三种多了个“N”。它表示存储的是Unicode数据类型的字符。我们知道中，英文字符只需要一个字节存储就足够了，但汉字众多，需要两个字节存储，英文与汉字同时存在时容易造成混乱，Unicode就是为了解决字符集这种不兼容的问题而产生的，它所有的字符都用两个字节表示，即英文字符也是用两个字节表示。nchar、nvarchar的长度是在1到4000之间。和char、varchar比较起来，nchar、nvarchar则最多存储4000个，不论是英文还是汉字；而char、varchar最多能存储8000个英文，4000个汉字。可以看出使用nchar、nvarchar数据类型时不用担心输入的是英文还是汉字，较为方便，但在英文时数量上有些损失。
所以一般来说，如果含有中文，用nchar/nvarchar，如果纯英文和数字，用char/varchar。
新手上路我有疑问投诉建议参考资料 查看数据库语言_百度百科
特色百科用户权威合作手机百科
收藏 查看&数据库语言本词条缺少信息栏、名片图，补充相关内容使词条更完整，还能快速升级，赶紧来吧！
SQL是高级的非过程化编程语言，允许用户在高层上工作。它不要求用户指定对数据的存放方法，也不需要用户了解具体的数据存放方式，所以具有完全不同底层结构的不同可以使用相同的SQL语言作为数据输入与管理的接口。
它以合作为操作对象，所有SQL语句接受集合作为输入，返回集合作为输出，这种集合特性允许一条SQL语句的输出作为另一条SQL语句的输入，所以SQL语句可以嵌套，这使他具有极大的灵活性和强大的功能，在多数情况下，在其他语言中需要一大段程序实现的功能只需要一个SQL语句就可以达到目的，这也意味着用SQL语言可以写出非常复杂的语句。[1]
(Structured Query Language)最早是的圣约瑟研究实验室为其SYSTEM R开发的一种查询语言，它的前身是SQUARE语言。SQL语言结构简洁，功能强大，简单易学，所以自从IBM公司1981年推出以来，SQL语言得到了广泛的应用。如今无论是像、、Informix、SQL Server这些大型的，还是像Visual Foxpro、PowerBuilder这些PC上常用的数据库开发系统，都支持SQL语言作为查询语言。[2]美国国家标准局(ANSI)与（ISO）已经制定了SQL标准。ANSI是一个美国工业和商业集团组织，负责开发美国的商务和通讯标准。ANSI同时也是ISO和International Electrotechnical Commission(IEC)的成员之一。ANSI 发布与相应的。1992年，ISO和IEC发布了SQL国际标准，称为SQL-92。ANSI随之发布的相应标准是ANSI SQL-92。ANSI SQL-92有时被称为ANSI SQL。尽管不同的关系数据库使用的SQL版本有一些差异，但大多数都遵循 ANSI SQL 标准。SQL Server使用ANSI SQL-92的扩展集，称为T-SQL，其遵循ANSI制定的 SQL-92标准。1970年，美国IBM研究中心的E.F.Codd连续发表多篇论文，提出关系模型。1972年，IBM公司开始研制实验型关系数据库管理系统SYSTEM R，为其配制的查询语言称为SQUARE（Specifying Queries As Relational Expression）语言，在该语言中使用了较多的数学符号。1974年，Boyce和Chamberlin把SQUARE修改为SEQUEL（Structured English QUEry Language）语言。这两个语言在本质上是相同的，但后者去掉了数学符号，采用英语单词表示和结构式的语法规则，看起来很像英语句子，用户比较欢迎这种形式的语言。后来SEQUEL简称为SQL（Structured Query Language）语言，即“结构化查询语言”。
在认识到关系模型的诸多优越性后，许多厂商纷纷研制关系数据库管理系统（例如：Oracle、DB2、Sybase等），这些数据库管理系统的操纵语言也以SQL参照。1986年10月美国国家标准化协会（ANSI）发布了X3.135-1986《数据库语言SQL》，1987年6月国际标准化组织（ISO）采纳其为国际标准。我们称其为“SQL-86”标准。1989年10月，ANSI又颁布了增强完整性特征的“SQL-89”标准。随后，ISO对该标准进行了大量的修改和扩充，在1992年8月发布了标准化文件“ISO/IEC 《数据库语言SQL》”，我们称其为SQL92或SQL2标准。1999年ISO又颁布了“ISO/IEC 《数据库语言SQL》”标准化文件，我们称其为SQL99或SQL3标准。--数据操作
SELECT --从数据库表中检索数据行和列
INSERT --向数据库表添加新数据行
DELETE --从数据库表中删除数据行
UPDATE --更新数据库表中的数据
--数据定义
CREATE TABLE --创建一个数据库表
DROP TABLE --从数据库中删除表
ALTER TABLE --修改数据库表结构
CREATE VIEW --创建一个视图
DROP VIEW --从数据库中删除视图
CREATE INDEX --为数据库表创建一个索引
DROP INDEX --从数据库中删除索引
CREATE PROCEDURE --创建一个
DROP PROCEDURE --从数据库中删除
CREATE TRIGGER --创建一个触发器
DROP TRIGGER --从数据库中删除触发器
CREATE SCHEMA --向数据库添加一个新模式
DROP SCHEMA --从数据库中删除一个模式
CREATE DOMAIN --创建一个数据值域
ALTER DOMAIN --改变域定义
DROP DOMAIN --从数据库中删除一个域
--数据控制
GRANT --授予用户访问权限
DENY --拒绝用户访问
REVOKE --解除用户访问权限
COMMIT --结束当前
ROLLBACK --中止当前事务
SET TRANSACTION --定义当前数据访问特征
--程序化SQL
DECLARE --为查询设定
EXPLAN --为查询描述数据访问计划
OPEN --检索查询结果打开一个
FETCH --检索一行查询结果
CLOSE --关闭
PREPARE --为动态执行准备SQL 语句
EXECUTE --动态地执行SQL 语句
DESCRIBE --描述准备好的查询
declare @id char(10)
--set @id = ';
select @id = ';
---[1][3]※(DDL)，例如：CREATE、DROP、ALTER等语句。
※(DML)，例如：INSERT（插入）、UPDATE（修改）、DELETE（删除）语句。
※ 数据查询语言(DQL)，例如：SELECT语句。（一般不会单独归于一类，因为只有一个语句）。
※(DCL)，例如：GRANT、REVOKE等语句。
※事务控制语句（TCL），例如：COMMIT、ROLLBACK等语句。
SQL语言包括四类种主要类别的语句：(DDL)，(DML)及(DCL)还有事务控制语言（TCL）。[2]
新手上路我有疑问投诉建议参考资料 查看1192人阅读
利用MySQL数据库如何解决大数据量存储问题？
各位高手您们好，我最近接手公司里一个比较棘手的问题，关于如何利用MySQL存储大数据量的问题，主要是数据库中的两张历史数据表，一张模拟量历史数据和一张开关量历史数据表，这两张表字段设计的很简单（OrderNo，Value，DataTime）。基本上每张表每天可以增加几千万条数据，我想问如何存储数据才能不影响检索速度呢？需不需要换oracle数据库呢？因为我是数据库方面的新手，希望可以说的详细一点，万分感谢！！?-0-#暂时可以先考虑用infobright
这是mysql的数据仓库解决方案如果这都满足不了需求 再考虑hadoop&
暂时可以先考虑用infobright&&这是mysql的数据仓库解决方案
如果这都满足不了需求&再考虑hadoop
好吧，你的检索SQL是怎么样的？
每张表每天几千万，对于写入性能的要求也就很高了。0/24，每秒要写入115条记录。
而且你的数据属于归档类数据，可以用mongodb来存储，写入速度和查询速度比MYSQL都要好很多。
提问：如何设计或优化千万级别的大表？此外无其他信息，个人觉得这个话题有点范，就只好简单说下该如何做，对于一个存储设计，必须考虑业务特点，收集的信息如下：
1.数据的容量：1-3年内会大概多少条数据，每条数据大概多少字节；&
2.数据项：是否有大字段，那些字段的值是否经常被更新；&
3.数据查询SQL条件：哪些数据项的列名称经常出现在WHERE、GROUP BY、ORDER BY子句中等；&
4.数据更新类SQL条件：有多少列经常出现UPDATE或DELETE 的WHERE子句中；&
5.SQL量的统计比，如：SELECT：UPDATE+DELETE：INSERT=多少？&
6.预计大表及相关联的SQL，每天总的执行量在何数量级？&
7.表中的数据：更新为主的业务 还是 查询为主的业务&
8.打算采用什么数据库物理服务器，以及数据库服务器架构？&
9.并发如何？&
10.存储引擎选择InnoDB还是MyISAM？&
大致明白以上10个问题，至于如何设计此类的大表，应该什么都清楚了！&
至于优化若是指创建好的表，不能变动表结构的话，那建议InnoDB引擎，多利用点内存，减轻磁盘IO负载，因为IO往往是数据库服务器的瓶颈&
另外对优化索引结构去解决性能问题的话，建议优先考虑修改类SQL语句，使他们更快些，不得已只靠索引组织结构的方式，当然此话前提是，&
索引已经创建的非常好，若是读为主，可以考虑打开query_cache，&
以及调整一些参数值：sort_buffer_size,read_buffer_size,read_rnd_buffer_size,join_buffer_size&
更多信息参见：
MySQL数据库服务器端核心参数详解和推荐配置
您好，主要是检索某段时间内的模拟量值（select&*&from&table&where&datatime&between&t1&and&t2&）,目前打算使用分表，分区的方式解决
不纸上谈兵，说一下我的思路以及我的解决，抛砖引玉了&
我最近正在解决这个问题&
我现在的公司有三张表，是5亿的数据，每天张表每天的增量是100w&
每张表大概在10个columns左右&
下面是我做的测试和对比&
1.首先看engine,在大数据量情况下，在没有做分区的情况下&
mysiam比innodb在只读的情况下，效率要高13％左右&
2.在做了partition之后，你可以去读一下mysql的官方文档，其实对于partition，专门是对myisam做的优化，对于innodb，所有的数据是存在ibdata里面的，所以即使你可以看到schema变了，其实没有本质的变化&
在分区出于同一个physical disk下面的情况下，提升大概只有1％&
在分区在不同的physical disk下，我分到了三个不同的disks下，提升大概在3％，其实所谓的吞吐量，由很多因素决定的，比如你的explain parition时候可以看到，record在那一个分区，如果每个分区都有，其实本质上没有解决读的问题，这样只会提升写的效率。&
另外一个问题在于，分区，你怎么分，如果一张表，有三个column都是经常被用于做查询条件的，其实是一件很悲惨的事情，因为你没有办法对所有的sql做针对性的分区，如果你只是如mysql官方文档上说的，只对时间做一个分区，而且你也只用时间查询的话，恭喜你&
3.表主要用来读还是写，其实这个问题是不充分的，应该这样问，你在写入的时候，同时并发的查询多么？我的问题还比较简单，因为mongodb的shredding支持不能，在crush之后，还是回到mysql，所以在通常情况下，9am－9pm，写入的情况很多，这个时候我会做一个view，view是基于最近被插入或者经常被查询的，通过做view来分离读取，就是说写是在table上的，读在进行逻辑判断前是在view上操作的&
4做一些archive table，比如先对这些大表做很多已有的统计分析，然后通过已有的分析＋增量来解决&
5如果你用mysiam，还有一个问题你要注意，如果你的.configure的时候，加了一个max index length参数的时候，当你的record数大于制定长度的时候，这个index会被disable&
照你的需求来看，可以有两种方式，一种是分表，另一种是分区
首先是分表，就像你自己所说的，可以按月分表，可以按用户ID分表等等，至于采用哪种方式分表，要看你的业务逻辑了，分表不好的地方就是查询有时候需要跨多个表。
然后是分区，分区可以将表分离在若干不同的表空间上，用分而治之的方法来支撑无限膨胀的大表，给大表在物理一级的可管理性。将大表分割成较小的分区可以改善表的维护、备份、恢复、事务及查询性能。分区的好处是分区的优点：
1　增强可用性：如果表的一个分区由于系统故障而不能使用，表的其余好的分区仍然可以使用；
2　减少关闭时间：如果系统故障只影响表的一部分分区，那么只有这部分分区需要修复，故能比整个大表修复花的时间更少；
3　维护轻松：如果需要重建表，独立管理每个分区比管理单个大表要轻松得多；
4　均衡I/O:可以把表的不同分区分配到不同的磁盘来平衡I/O改善性能；
5　改善性能：对大表的查询、增加、修改等操作可以分解到表的不同分区来并行执行，可使运行速度更快；
6　分区对用户透明，最终用户感觉不到分区的存在。
&如今随着互联网的发展，数据的量级也是撑指数的增长，从GB到TB到PB。对数据的各种操作也是愈加的困难，传统的关系性数据库已经无法满足快速查询与插入数据的需求。这个时候NoSQL的出现暂时解决了这一危机。它通过降低数据的安全性，减少对事务的支持，减少对复杂查询的支持，来获取性能上的提升。但是，在有些场合NoSQL一些折衷是无法满足使用场景的，就比如有些使用场景是绝对要有事务与安全指标的。这个时候NoSQL肯定是无法满足的，所以还是需要使用关系性数据库。
& 虽然关系型数据库在海量数据中逊色于NoSQL数据库，但是如果你操作正确，它的性能还是会满足你的需求的。针对数据的不同操作，其优化方向也是不尽相同。对于数据移植，查询和插入等操作，可以从不同的方向去考虑。而在优化的时候还需要考虑其他相关操作是否会产生影响。就比如你可以通过创建索引提高查询性能，但是这会导致插入数据的时候因为要建立更新索引导致插入性能降低，你是否可以接受这一降低那。所以，对数据库的优化是要考虑多个方向，寻找一个折衷的最佳方案。
& 一：查询优化
& 1：创建索引。
& 最简单也是最常用的优化就是查询。因为对于CRUD操作，read操作是占据了绝大部分的比例，所以read的性能基本上决定了应用的性能。对于查询性能最常用的就是创建索引。经过测试，2000万条记录，每条记录200字节两列varchar类型的。当不使用索引的时候查询一条记录需要一分钟，而当创建了索引的时候查询时间可以忽略。但是，当你在已有数据上添加索引的时候，则需要耗费非常大的时间。我插入2000万条记录之后，再创建索引大约话费了几十分钟的样子。
& 创建索引的弊端和场合。虽然创建索引可以很大程度上优化查询的速度，但是弊端也是很明显的。一个是在插入数据的时候，创建索引也需要消耗部分的时间，这就使得插入性能在一定程度上降低；另一个很明显的是数据文件变的更大。在列上创建索引的时候，每条索引的长度是和你创建列的时候制定的长度相同的。比如你创建varchar(100)，当你在该列上创建索引，那么索引的长度则是102字节，因为长度超过64字节则会额外增加2字节记录索引的长度。
& 从上图可以看到我在YCSB_KEY这一列(长度100)上创建了一个名字为index_ycsb_key的索引，每条索引长度都为102，想象一下当数据变的巨大无比的时候，索引的大小也是不可以小觑的。而且从这也可以看出，索引的长度和列类型的长度还不同，比如varchar它是变长的字符类型()，实际存储长度是是实际字符的大小，但是索引却是你声明的长度的大小。你创建列的时候声明100字节，那么索引长度就是这个字节再加上2，它不管你实际存储是多大。
& 除了创建索引需要消耗时间，索引文件体积会变的越来越大之外，创建索引也需要看的你存储数据的特征。当你存储数据很大一部分都是重复记录，那这个时候创建索引是百害而无一利。请先查看。所以，当很多数据重复的时候，索引带来的查询提升的效果是可以直接忽略的，但是这个时候你还要承受插入数据的时候创建索引带来的性能消耗。
& 2：缓存的配置。
& 在MySQL中有多种多样的缓存，有的缓存负责缓存查询语句，也有的负责缓存查询数据。这些缓存内容客户端无法操作，是由server端来维护的。它会随着你查询与修改等相应不同操作进行不断更新。通过其配置文件我们可以看到在MySQL中的缓存：
& 在这里主要分析query cache，它是主要用来缓存查询数据。当你想使用该cache，必须把query_cache_size大小设置为非0。当设置大小为非0的时候，server会就会缓存每次查询返回的结果，到下次相同查询server就直接从缓存获取数据，而不是再执行查询。能缓存的数据量就和你的size大小设置有关，所以当你设置的足够大，数据可以完全缓存到内存，速度就会非常之快。
& 但是，query cache也有它的弊端。当你对数据表做任何的更新操作(update/insert/delete)等操作，server为了保证缓存与数据库的一致性，会强制刷新缓存数据，导致缓存数据全部失效。所以，当一个表格的更新数据表操作非常多的话，query cache是不会起到查询提升的性能，还会影响其他操作的性能。
& 3：slow_query_log分析。
& 其实对于查询性能提升，最重要也是最根本的手段也是slow_query的设置。
& 当你设置slow_query_log为on的时候，server端会对每次的查询进行记录，当超过你设置的慢查询时间(long_query_time)的时候就把该条查询记录到日志。而你对性能进行优化的时候，就可以分析慢查询日志，对慢查询的查询语句进行有目的的优化。可以通过创建各种索引，可以通过分表等操作。那为什么要分库分表那，当不分库分表的时候那个地方是限制性能的地方啊。下面我们就简单介绍。
& 4：分库分表
& 分库分表应该算是查询优化的杀手锏了。上述各种措施在数据量达到一定等级之后，能起到优化的作用已经不明显了。这个时候就必须对数据量进行分流。分流一般有分库与分表两种措施。而分表又有垂直切分与水平切分两种方式。下面我们就针对每一种方式简单介绍。
& 对于mysql，其数据文件是以文件形式存储在磁盘上的。当一个数据文件过大的时候，操作系统对大文件的操作就会比较麻烦与耗时，而且有的操作系统就不支持大文件，所以这个时候就必须分表了。另外对于mysql常用的存储引擎是Innodb，它的底层数据结构是B+树。当其数据文件过大的时候，B+树就会从层次和节点上比较多，当查询一个节点的时候可能会查询很多层次，而这必定会导致多次IO操作进行装载进内存，肯定会耗时的。除此之外还有Innodb对于B+树的锁机制。对每个节点进行加锁，那么当更改表结构的时候，这时候就会树进行加锁，当表文件大的时候，这可以认为是不可实现的。&
& 所以综上我们就必须进行分表与分库的操作。
&二：数据转移
& 当数据量达到一定等级之后，那么移库将是一个非常慎重又危险的工作。在移库中保证前后数据的一致性，各种突发情况的处理，移库过程中数据的变迁，每一个都是一个非常困难的问题。
& 2.1：插入数据
& 当进行数据迁移的时候，肯定会存在大数据的重新导入，你可以选择直接load文件，有的时候可能就需要代码插入了。这个时候就需要对插入语句进行一定的优化了。这个时候可以使用INSERT DELAYED语句，该语句是当你发出插入请求的时候，部马上就插入到数据库而是放在缓存里面，等待时机成熟之后再进行插入。
待补充。。。
分表是个目前算是比较炒的比较流行的概念，特别是在大负载的情况下，分表是一个良好分散数据库压力的好方法。
首先要了解为什么要分表，分表的好处是什么。我们先来大概了解以下一个数据库执行SQL的过程：
接收到SQL --& 放入SQL执行队列 --& 使用分析器分解SQL --& 按照分析结果进行数据的提取或者修改 --& 返回处理结果
当然，这个流程图不一定正确，这只是我自己主观意识上这么我认为。那么这个处理过程当中，最容易出现问题的是什么？就是说，如果前一个SQL没有执行完毕的话，后面的SQL是不会执行的，因为为了保证数据的完整性，必须对数据表文件进行锁定，包括共享锁和独享锁两种锁定。共享锁是在锁定的期间，其它线程也可以访问这个数据文件，但是不允许修改操作，相应的，独享锁就是整个文件就是归一个线程所有，其它线程无法访问这个数据文件。一般MySQL中最快的存储引擎MyISAM，它是基于表锁定的，就是说如果一锁定的话，那么整个数据文件外部都无法访问，必须等前一个操作完成后，才能接收下一个操作，那么在这个前一个操作没有执行完成，后一个操作等待在队列里无法执行的情况叫做阻塞，一般我们通俗意义上叫做“锁表”。
锁表直接导致的后果是什么？就是大量的SQL无法立即执行，必须等队列前面的SQL全部执行完毕才能继续执行。这个无法执行的SQL就会导致没有结果，或者延迟严重，影响用户体验。
特别是对于一些使用比较频繁的表，比如SNS系统中的用户信息表、论坛系统中的帖子表等等，都是访问量大很大的表，为了保证数据的快速提取返回给用户，必须使用一些处理方式来解决这个问题，这个就是我今天要聊到的分表技术。
分表技术顾名思义，就是把若干个存储相同类型数据的表分成几个表分表存储，在提取数据的时候，不同的用户访问不同的表，互不冲突，减少锁表的几率。比如，目前保存用户分表有两个表，一个是user_1表，还有一个是 user_2 表，两个表保存了不同的用户信息，user_1 保存了前10万的用户信息，user_2保存了后10万名用户的信息，现在如果同时查询用户 heiyeluren1 和 heiyeluren2 这个两个用户，那么就是分表从不同的表提取出来，减少锁表的可能。
我下面要讲述的两种分表方法我自己都没有实验过，不保证准确能用，只是提供一个设计思路。下面关于分表的例子我假设是在一个贴吧系统的基础上来进行处理和构建的。（如果没有用过贴吧的用户赶紧Google一下）
二、基于基础表的分表处理
这个基于基础表的分表处理方式大致的思想就是：一个主要表，保存了所有的基本信息，如果某个项目需要找到它所存储的表，那么必须从这个基础表中查找出对应的表名等项目，好直接访问这个表。如果觉得这个基础表速度不够快，可以完全把整个基础表保存在缓存或者内存中，方便有效的查询。
我们基于贴吧的情况，构建假设如下的3张表：
1. 贴吧版块表: 保存贴吧中版块的信息
2. 贴吧主题表：保存贴吧中版块中的主题信息，用于浏览
3. 贴吧回复表：保存主题的原始内容和回复内容
“贴吧版块表”包含如下字段：
版块ID&&&&&& board_id&&&&&&&&& int(10)
版块名称&&& board_name&&&&& char(50)
子表ID&&&&&& table_id&&&&&&&&&&& smallint(5)
产生时间&&& created&&&&&&&&&&&& datetime
“贴吧主题表”包含如下字段：
主题ID&&&&&&&&& topic_id&&&&&&& int(10)
主题名称&&&&&&& topic_name&&&& char(255)
版块ID&&&&&&&&& board_id&&&&&&&&& int(10)
创建时间&&&&&& created&&&&&&&&&& datetime
“贴吧回复表”的字段如下：
回复ID&&&&&&& reply_id&&&&&&&&&& int(10)
回复内容&&&&& reply_text&&&&&&& text
主题ID&&&&&&& topic_id&&&&&&&&&& int(10)
版块ID&&&&&&& board_id&&&&&&&& int(10)
创建时间&&&&& created&&&&&&&&&&& datetime
那么上面保存了我们整个贴吧中的表结构信息，三个表对应的关系是：
版块&--&&多个主题
主题&--&&多个回复
那么就是说，表文件大小的关系是：
版块表文件&&&主题表文件&&&回复表文件
所以基本可以确定需要对主题表和回复表进行分表，已增加我们数据检索查询更改时候的速度和性能。
看了上面的表结构，会明显发现，在“版块表”中保存了一个&table_id&字段，这个字段就是用于保存一个版块对应的主题和回复都是分表保存在什么表里的。
比如我们有一个叫做“PHP”的贴吧，board_id是1，子表ID也是1，那么这条记录就是：
board_id | board_name | table_id | created
1 | PHP | 1 |
相应的，如果我需要提取“PHP”吧里的所有主题，那么就必须按照表里保存的table_id来组合一个存储了主题的表名称，比如我们主题表的前缀是“topic_”，那么组合出来“PHP”吧对应的主题表应该是：“topic_1”，那么我们执行：
SELECT * FROM topic_1 WHERE board_id = 1 ORDER BY topic_id DESC LIMIT 10
这样就能够获取这个主题下面回复列表，方便我们进行查看，如果需要查看某个主题下面的回复，我们可以继续使用版块表中保存的“table_id”来进行查询。比如我们回复表的前缀是“reply_”，那么就可以组合出“PHP”吧的ID为1的主题的回复：
SELECT * FROM reply_1 WHERE topic_id = 1 ORDER BY reply_id DESC LIMIT 10
这里，我们能够清晰的看到，其实我们这里使用了基础表，基础表就是我们的版块表。那么相应的，肯定会说：基础表的数据量大了以后如何保证它的速度和效率？
当然，我们就必须使得这个基础表保持最好的速度和性能，比如，可以采用MySQL的内存表来存储，或者保存在内存当中，比如Memcache之类的内存缓存等等，可以按照实际情况来进行调整。
一般基于基础表的分表机制在SNS、交友、论坛等Web2.0网站中是个比较不错的解决方案，在这些网站中，完全可以单独使用一个表来来保存基本标识和目标表之间的关系。使用表保存对应关系的好处是以后扩展非常方便，只需要增加一个表记录。
【优势】增加删除节点非常方便，为后期升级维护带来很大便利
【劣势】需要增加表或者对某一个表进行操作，还是无法离开数据库，会产生瓶颈
三、基于Hash算法的分表处理
我们知道Hash表就是通过某个特殊的Hash算法计算出的一个值，这个值必须是惟一的，并且能够使用这个计算出来的值查找到需要的值，这个叫做哈希表。
我们在分表里的hash算法跟这个思想类似：通过一个原始目标的ID或者名称通过一定的hash算法计算出数据存储表的表名，然后访问相应的表。
继续拿上面的贴吧来说，每个贴吧有版块名称和版块ID，那么这两项值是固定的，并且是惟一的，那么我们就可以考虑通过对这两项值中的一项进行一些运算得出一个目标表的名称。
现在假如我们针对我们这个贴吧系统，假设系统最大允许1亿条数据，考虑每个表保存100万条记录，那么整个系统就不超过100个表就能够容纳。按照这个标准，我们假设在贴吧的版块ID上进行hash，获得一个key值，这个值就是我们的表名，然后访问相应的表。
我们构造一个简单的hash算法：
function get_hash($id){
&&&& $str = bin2hex($id);
&&&& $hash = substr($str, 0, 4);
&&&& if (strlen($hash)&4){
&&&&&&&& $hash = str_pad($hash, 4, &0&);
&&&& return $
算法大致就是传入一个版块ID值，然后函数返回一个4位的字符串，如果字符串长度不够，使用0进行补全。
比如：get_hash(1)，输出的结果是“3100”，输入：get_hash(23819)，得到的结果是：3233，那么我们经过简单的跟表前缀组合，就能够访问这个表了。那么我们需要访问ID为1的内容时候哦，组合的表将是：topic_3100、reply_3100，那么就可以直接对目标表进行访问了。
当然，使用hash算法后，有部分数据是可能在同一个表的，这一点跟hash表不同，hash表是尽量解决冲突，我们这里不需要，当然同样需要预测和分析表数据可能保存的表名。
如果需要存储的数据更多，同样的，可以对版块的名字进行hash操作，比如也是上面的二进制转换成十六进制，因为汉字比数字和字母要多很多，那么重复几率更小，但是可能组合成的表就更多了，相应就必须考虑一些其它的问题。
归根结底，使用hash方式的话必须选择一个好的hash算法，才能生成更多的表，然数据查询的更迅速。
【优点hash算法直接得出目标表名称，效率很高】通过
【劣势】扩展性比较差，选择了一个hash算法，定义了多少数据量，以后只能在这个数据量上跑，不能超过过这个数据量，可扩展性稍差
四、其它问题
1.&搜索问题
现在我们已经进行分表了，那么就无法直接对表进行搜索，因为你无法对可能系统中已经存在的几十或者几百个表进行检索，所以搜索必须借助第三方的组件来进行，比如Lucene作为站内搜索引擎是个不错的选择。
2.&表文件问题
我们知道MySQL的MyISAM引擎每个表都会生成三个文件，*.frm、*.MYD、*.MYI 三个文件，分表用来保存表结构、表数据和表索引。Linux下面每个目录下的文件数量最好不要超过1000个，不然检索数据将更慢，那么每个表都会生成三个文件，相应的如果分表超过300个表，那么将检索非常慢，所以这时候就必须再进行分，比如在进行数据库的分离。
使用基础表，我们可以新增加一个字段，用来保存这个表保存在什么数据。使用Hash的方式，我们必须截取hash值中第几位来作为数据库的名字。这样，完好的解决这个问题。
在大负载应用当中，数据库一直是个很重要的瓶颈，必须要突破，本文讲解了两种分表的方式，希望对很多人能够有启发的作用。当然，本文代码和设想没有经过任何代码测试，所以无法保证设计的完全准确实用，具体还是需要读者在使用过程当中认真分析实施。
文章写的比较匆忙，质量可能无法保证，遇到错误，不要见怪，欢迎提出批评指教，谢谢~~~~！
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：197738次
积分：3058
积分：3058
排名：第4132名
原创：61篇
转载：343篇
评论：38条
(18)(23)(13)(21)(11)(3)(14)(30)(18)(8)(8)(14)(12)(18)(16)(29)(28)(34)(16)(3)(8)(19)(18)(3)(2)(6)(3)(6)(6)