Schema与数据类型优化的方法

这篇文章主要介绍Schema与数据类型优化的方法，文中介绍的非常详细，具有一定的参考价值，感兴趣的小伙伴们一定要看完！schema就是数据库对象的集合，这个集合包含了各种对象如：表、视图、存储过程、索引等。为了区分不同的集合，就需要给不同的集合起不同的名字，默认情况下一个用户对应一个集合，用户的schema名等于用户名，并作为该用户缺省schema。所以schema集合看上去像用户名。如果把database看作是一个仓库，仓库很多房间（schema），一个schema代表一个房间，table可以看作是每个房间中的储物柜，user是每个schema的主人，有操作数据库中每个房间的权利，就是说每个数据库映射的user有每个schema（房间）的钥匙。 SQL server和Oracle mysql有别1、更小的通过更好，尽量使用可正确存储数据的最小的数据类型（占更少的磁盘 内存 CPU缓存，处理时需要CPU周期更少：更快），但能罩得住数据，存不下就尴尬了2、简单就好：简单类型（更少CPU周期），使用MySQL内建类型存时间，整型存ip，整型较字符代价低（字符集和校对排序规则使字符较复杂）3、尽量避免null：最好指定为not null*）null列使用更多的存储空间，mysql里需要特殊处理*）null使索引、索引统计和值比较更复杂；可为null的列被索引时，每个索引记录需额外的字节例外：InnoDB使用单独位bit存储null,so对于稀疏数据（很多值为null）有很好的空间效率，不适合MyISAMtinyint(8位存储空间) smallint(16) mediumint(24) int(32) bigint(64)1、存储值的范围：，N是存储空间的位数2、unsigned：可选、不容许负值，可使正数的上限提高一倍：tinyint unsigned 0~255，tinyint-128~1273、有无符号使用相同的存储空间，相同的性能可为整型指定宽度，例如INT(11)，对于大多数应用无意义，不会限制值的合法范围，只是规定了交互工具显示字符的个数，对于存储和计算，int（1）和int（20）是相同的；float和double，mysql使用duble作为内部浮点计算的类型decimal：存储精确的小数，mysql服务器自身实现，decimal(18,9)18位，9位小数，9个字节（前4后4点1）尽量只在对小数进行精确计算时才使用（额外的空间和计算开销），如财务数据数据量大时，考虑使用bigint代替，将需要存储的货币单位据小数的位数乘以相应的倍数浮点：建议：只指定类型、不定精度（mysql），这些精度非标准，mysql会悄选类型、或存时对值取舍存储同样范围的值时，比decimal更少的空间，float4字节存 double8字节（更高精度范围）前提：innodb和myisam引擎，最主要的字符串类型磁盘存储：存储引擎存储的方式与在内存、磁盘上的不能不一样，所以mysql服务器从引擎取值需转格式varchar：1、存储可变字符串，比定长节省空间（仅使用必要的空间），但如果表使用row_format=fixed，行会定长存储2、需使用1/2额外字节记录字符串长度；1）列max长度
3、节省存储空间，利于性能；但在update可能使行变得比原来更长、需做额外工作合适的情况：1）字符串列最大长度比平均长度大很多；2）列的更新少（不担心碎片）；3）使用UTF-8字符串，每个字符均使用不同的字节数存储char：1、定长，据长度分配空间，删除all末尾空格；长度不够、空格填充2、存储空间上更有效率，char(1)来存储只有Y N的值 1个字节 ，varchar2字节，还有一个记录长度适合的情况：1）适合存储很短的字符串；2）或all值接近同一个长度；3）经常变更的数据，存储不易碎片对应空格、存储：char类型存储时末尾空格被删；数据如何存储取决于存储引擎，Memory引擎只支持定长的行（最大长度分配空间）binary，varbinary：存储二进制字符串，字节码，长度不够、来凑（不是空格）检索时不会去慷慨不是明智的：varchar（5）和varchar（100）存储‘hell’空间开销一样，长的列消耗更多内存分别用二进制和字符方式存储，分别属于两组不同的数据类型：字符类型：tinytext、smallt开发云主机域名ext、text、mediumtext、longtext，对应的二进制类型是tinyblob、smallblob、blob、mediumblob、longblob，两类仅有的不同：blob类型存储的是二进制，无排序规则或字符集，text有字符串 排序规则；MySQL会把每个blob和text当做独立的对象处理，存储引擎存储时会做特殊处理，当值太大，innoDB使用专门的外部存储区域进行存储，此时每个值在行内需要1~4个字节存储一个指针，然后在外部存储实际的值；mysql对他们的列排序：只对每列前max_sort_length字节排序；且不能将列全部长度的字符串进行索引，也不能使用这些索引消除排序；如果explain执行计划的extra包含using temporary：这个查询使用了隐式临时表定义时指定取值范围，对1～255个成员的枚举需要1个字节存储；对于256～65535个成员，需要2个字节存储。最多可以有65535个成员，ENUM类型只能从成员中选择一个；和set相似可把不重复的固定的字符串存储成一个预定义的集合，mysql在存储枚举时会据列表值的数量压缩到1/2字节中，在内部会将每个值在列表中的位置保存为整数（从1开始，必须进行查找才能转换为字符串，开销、列表小 可控），且在表的.frm文件中保持“数字-字符串”映射关系的“查找表”；将一个数字存储到一个 ENUM 中，数字被当作为一个索引值，并且存储的值是该索引值所对应的枚举成员： 在一个 ENUM字符串中存储数字是不明智的，因为它可能会打乱思维；ENUM 值依照列规格说明中的列表顺序进行排序。(ENUM 值依照它们的索引号排序。)举例来说，对于 ENUM("a", "b") "a" 排在 "b" 后，但是对于 ENUM("b", "a")， "b" 却排在 "a" 之前。空字符串排在非空字符串前，NULL 值排在其它所有的枚举值前。为了防止意想不到的结果，建议依照字母的顺序定义 ENUM列表。也可以通过使用GROUP BY CONCAT(col) 来确定该以字母顺序排序而不是以索引值。【源】排序时安装创建表时的顺序排序的（应该是）；枚举最不好的地方：字符串列表是固定的，添加删除字符串须使用alter table；在‘查找表’时采用整数主键避免基于字符串的值进行关联；默认，以可排序、无歧义的格式显示datetime：2008-01-02 22:33:44from_unixtime将unix时间戳转日期，unix_timestamp将日期转unix时间戳插入时没有指定第一个timestamp列的值，设置为当前时间，插入记录时，默认更新第一个timestamp列的值，timestamp类为not null，尽量使用timestamp（空间效率高）；可以使用bigint类型存储微妙级别的时间戳，或double存秒之后的小数部分，或使用MariaDB代替MySQL；前与tinyint同义词，新特性bit（1）单个位的字段，bit（2）2个位，最大长度64个位 行为因存储引擎而异，MyISAM打包存储all的BIT列（17个单独的bit列只需要17个位存储，myisam3字节ok），其他引擎Memory和innoDB为每bit列使用足够存储的最小整数类型来存放，不节省存储空间； mysql把bit当做字符串类型，检索bit（1）值、结果是包含二进制0/1的字符串，数字上下文的场景检索，将字符串转成数字，大部分应用，best避免使用；创建表时，就指定SET类型的取值范围 ：属性名 SET(‘值1′,’值2′,’值3’…,’值n’)，“值n”参数表示列表中的第n个值，这些值末尾的空格将会被系统直接删除，字段元素顺序 系统自动按照定义时的顺序显示 重复 只存一次。其基本形式与ENUM类型一样。SET类型的值可以取列表中的一个元素或者多个元素的组合。取多个元素时，不同元素之间用逗号隔开。SET类型的值最多只能是有64个元素构成的组合，根据成员的不同，存储上也有所不同：【参考，同enum】需要保持很多true、false值，可考虑合并这些列到set类型，在mysql内部以一系列打包的位的集合来表示的（有效利用存储空间）且mysql有find_in_set、field函数，方便在查询中使用；缺点：改变列的定义代价高，需要alter table，无法再set上通索引查找在整数列按位操作：代替set的方式：使用整数包装一系列的位：可把8个位包装到tinyint中，且按位操作来使用，为位定义名称常量来简化这个工作，但是这样查询语句较难写且难理解1）可不用手动插入值，系统提供默认序列值;2)不要求和主键搭配 ; 3)要求是unique key；4）一个表最多一个；5）类型只能是数值；5）可通过set auto_increment_increment=3;选择标识列类型时考虑存储类型、mysql对这种类型怎么执行计算和比较，确定后确保在all关联表中使用same类型，类型间要精确匹配；技巧：1、整数类型：整数通常最好的选择，很快且可使用auto_increment2、enum和set类型，存储固定信息3、字符串：避免，耗空间较数字慢，myisam表特别小心（默认对字符串压缩使用、查询慢）1）完全“随机”字符串MD5/SHA1/UUID函数生成的新值 会任意分布在很大的空间内，导致insert及部分的select变慢：插入值随机的写到索引的不同位置，insert变慢(页分裂 磁盘随机访问 聚簇索引碎片）；select变慢、逻辑上相邻的行分布在磁盘和内存不同的地方；随机值导致缓存对all类型的查询语句效果都变差（使缓存赖以工作的访问局部性原理失效） 聚簇索引，实际存储的循序结构与数据存储的物理结构一致，通常来说物理顺序结构只有一种，一个表的聚簇索引也只能有一个，通常默认都是主键，设置了主键，系统默认就为你加上了聚簇索引；【源】非聚簇索引记录的物理顺序与逻辑顺序没有必然的联系，与数据的存储物理结构没有关系；一个表对应的非聚簇索引可以有多条，根据不同列的约束可以建立不同要求的非聚簇索引；2）存储uuid，移除-符号，或者用unhex转换uuid值为16字节的数字，且存储在binary（16）列中，检索时通过hex函数格式化为16进制格式;UUID生成的值与加密散列函数(sha1)生成的值不同特征：uuid分布不均匀，有一定顺序，不如递增整数严重性能问题，很大的varchar、关联列不同的类型； orm会存储任意类型的数据到任意类型的后端数据存储中，并没有设计使用更优的类型存储，有时为每个对象每个属性使用单独行，设置使用基于时间戳的版本控制，导致单个属性会有多个版本存在；权衡以上是“Schema与数据类型优化的方法”这篇文章的所有内容，感谢各位的阅读！希望分享的内容对大家有帮助，更多相关知识，欢迎关注开发云行业资讯频道！

相关推荐: MySQL误操作数据恢复的简单实践（r11笔记第67天）

前几天有个同事碰到了一个MySQL数据恢复的问题，他运行了一条update语句，结果忘记了加where条件，结果等反应过来已经晚了。我简单确认了下，是否存在备份，没有，是否开启了日志，没有。所以这个恢复无从谈起。 当然后来他也花了些功夫逐条数据修复，事情过去了…