高性能MySql-Schema与数据类型优化1

高性能MySql阅读笔记第四章--Schema与数据类型优化阅读笔记

良好的逻辑设计和物理设计是高性能的基石,应该根据系统将要执行的查询语句来设计schema,这往往需要权衡各种因素。

本章主要为接下来的索引优化与查询优化做铺垫,覆盖了MySql特有的schem设计方面的主题:

一.选择优化的数据类型

  Mysql支持的数据类型非常多,选择正确的数据类型对于获得高性能至关重要。在为列选择数据类型时,第一步需要确定合适的大类型,下一步是选择具体类型相同大类型下的不同子类型数据有时也有一些特殊的行为和属性。

  1.更小的数据类型通常更好

  2.简单就好

  3.尽量避免NULL

二.整数类型

可以使用的几种整数类型:TINYINT,SMALLINT,MEDIUMINT,INT,BIGINT分别使用8,16,24,32,64位存储空间。

整数类型有可选的UNSIGNED属性,表示不允许负值,这大致可以使正数的上限提高一倍。

整数计算一般使用64位的BIGINT整数,即使32位环境也是如此(一些聚合函数是例外,他们使用DECIMAL或DOUBLE进行计算)。

三.实数类型

FLOAT和DOUBLE类型支持使用标准的浮点运算进行近似计算。DECIMAL类型用于存储精确的小数,Mysql服务器自身实现了DECIMAL的高精度计算,相对而言,CPU直接支持原生浮点计算,所以浮点计算明显更快。

浮点和DECIMAL类型都可以指定精度,对于DECIMAL可以指定小数点前后所允许的最大位数,这会影响列的空间消耗。

浮点类型在存储同样范围的值时,通常比DECIMAL使用更少的空间,所以应该尽量只在对小数进行精确计算时才使用。

四.字符串类型

VARCHAR和CHAR是两种最主要的字符串类型。

VARCHAR类型存储可变长字符串,他比定长类型更节省空间,VARCHAR节省了存储空间,所以对性能也有帮助,但由于是变长的,在UPDATE时可能使行变得比原来长,这就导致需要做额外的工作。

CHAR是定长的,适合存储很短的字符串(末尾会用空格填充)。

五.BLOB和TEXT类型

Mysql把每个BLOB和TEXT值当作一个独立的对象处理。

六.使用枚举(ENUM)代替字符串类型

有时候可以使用枚举代替常用的字符串类型,枚举把一些不重复的字符串存储成一个预定义的集合。枚举在保存时是(数字-字符串)的形式。

七.日期和时间类型

Mysql使用许多类型保存日期和时间值,例如year和date,Mysql能存储的最小时间粒度为秒,Mysql提供两种相似的日期类型:DATETIME和TIMESTAMP,在某些场合一个比另一个工作的更好。

DATETIME

这个类型保存的最大值从1001到9999年,精度为秒。

TIMESTAMP使用4个字节保持日期,默认NOT NULL。

八.位数据类型

BIT 最大长度64个位。Mysql把BIT当作字符串类型,而不是数字类型。

SET 一系列打包位的集合。Mysql有像FIND_IN_SET和FIELD这样的函数,方便在查询中使用。他的主要缺点是改变列的代价太高,也无法在SET上通过索引查找。

九.选择标识符。通常为整数类型和字符串。

十.特殊类型数据,例如毫秒级时间,IP地址,可以在使用时进行相应转换。

时间: 2024-10-23 11:31:09

高性能MySql-Schema与数据类型优化1的相关文章

高性能mysql - Schema与数据类型优化

MySQL支持的数据类型非常多,选择正确的数据类型对于获得高性能至关重要.选择数据类型的几个原则1.更小的通常更好2.简单就好,如使用date,time,datetime来存储时间而不是字符串 3.尽量避免NULL, 某个字段如果计划建索引,就应该尽量把这个字段设计成NOT NULL DATETIME 与 TIMESTAMPTIMESTAMP 更小, 但是允许的时间范围小. 整数类型TINYINT 8位存储空间,SMALLINT 16位存储空间, MEDIUMINT 24位存储空间, INT 3

高性能Mysql——Schema与数据类型优化

良好的逻辑设计和物理设计师高性能的基石 一.选择优化的数据类型 更小的通常更好 占用更小的磁盘.内存.CPU缓存和处理时需要的CPU周期 简单就好 操作需要更少的CPU周期,例如:整型比字符型操作代价更低,以为字符集和校对规则使字符比整型更复杂.应该使用Mysql内建的类型而不是字符串来存储日期和时间,另外一个是应该用整型存储IP地址. 尽量避免NULL 通常情况最好指定列为not null,除非真的需要存储null值.如果查询包含null的列,对Mysql的来说更难优化,null的列是的索引.

MySQL Schema与数据类型优化

Schema与数据类型优化 选择优化的数据类型 1.更小的通常更好 更小的数据类型通常更快,因为它们占用更少的磁盘,内存和CPU缓存 2.简单就好 简单数据类型的操作通常需要更少的CPU周期.例如:整型比字符操作代价更低,因为字符集和校对规则使字符比较比整型比较更复杂 3.尽量避免NULL 通常情况下最好制定列为NOT NULL,除非真的需要存储NULL值. 如果查询中包含可为NULL的列,对MySQL来说更难优化,因为可为NULL的列使得索引.索引统计和值比较都更复杂.可为NULL的列会使用更

高性能MySQL(四)—Schema与数据类型优化(1)

Schema与数据类型优化 选择优化的数据类型 下面是一些简单的原则: 更小的通常更好 一般情况下,应该尽量使用可以正确存储的最小数据类型.如:只需要存储0-200, tinyint unsigned就比较好.小的数据类型占的磁盘.内存和CPU缓存都较少,并且处理时需要的CPU周期数也更少. 简单就好 简单数据类型额操作通常需要更少的CPU周期.如:应该使用MySQL的內建类型来存储时间和日期而不是字符串.如:应该用整型存储IP地址. 尽量避免null 通常情况下最好指定列为NOT NULL,除

【MySQL】《高性能MySQL》学习笔记,第四章,Schema与数据类型优化

[MySQL]<高性能MySQL>学习笔记,第四章,Schema与数据类型优化 良好的逻辑设计和物理设计是高性能的基石,应该根据系统将要执行的查询语句来设计schema. 反范式的设计可以加快某些类型的查询,单同时可能使另一类型的查询变慢,比如添加计数表和汇总表是一种很好的优化查询的方式,但这些表的维护成本可能会很高. 1.选择优化的数据类型 更小的通常更好. ? 应该尽量使用可以正确存储数据的最小类型,更小的数据类型通常更快,因为他们占用更少的磁盘,内存和CPU缓存,并且处理时需要的CPU周

mysql笔记01 Schema与数据类型优化

Schema与数据类型优化 1. 选择优化的数据类型 1). 更小的通常更好:更小的数据类型通常更快,因为他们占用更少的磁盘.内存和CPU缓存,并且处理需要的CPU周期也更少. 2). 简单就好:简单的数据类型的操作通常需要更少的CPU周期.例如:整型比字符串操作的代价更低,因为字符集和校对规则(排序规则)是字符串比较比整型比较更复杂.这里有两个例子: 一个是应该使用MySQL内建的类型而不是字符串来存储日期和时间,另外一个是应该使用整型存储IP地址. 3). 避免使用null:通常情况下最好指

mysql的schema与数据类型优化分析

Schema与数据类型优化: 1.选择优化的数据类型 更小的通常更好:一般情况下,尽量使用可以正确存储数据的最小数据类型 如:只需存0-200,tinyint unsigned更好. 简单就好:如:整型比字符串操作代价更低,应该使用mysql内建类型而不是字符串来存储日期和时间. 尽量避免NULL:通常情况下最好指定列为NOT NULL,除非真的要存储NULL值.如:查询中包含可为NULL的列对mysql来说更难优化. 2. 选择类型范围 如DATETIME和TIMESTAMP列都可以存储相同类

Schema与数据类型优化

Schema与数据类型优化 1.选择优化的数据类型 应该尽量使用可以存储数据的更小的数据类型.更小的数据类型通常更快,占用更少的磁盘.内存.缓存. 2.简单最好 整型比字符型要好,两个例子,应该使用Mysql内建的类型来存储日期而不是字符串:使用整形存储Ip地址.因为字符的校对.排序规则要复杂. 3.尽量避免使用Null. 因为可为Null的列使得索引和索引统计和值的比较变得复杂. 4.整数类型 整数类型分为:tinyint.smallint.mediumint.int.bigint.Mysql

《高性能MySQL》- 04 Schema与数据类型优化

选择优化的数据类型 下面几个简单的原则有助于做出更好的选择: 更小的通常更好.一般情况下,尽可能使用可以正确存储数据的最小数据类型.它们通常更快,站更少的磁盘,内存和cpu缓存.但需要确保没有低估存储的值的范围 简单就好.简单数据类型通常也是需要更少的cpu周期.例如,整型比字符操作代价更低.有两个需要先记着,一个是使用MySQL的内建类型,而不是字符串来创建时间,第二个是用整型存储IP地址.之后会讨论 尽量避免NULL.通常情况下最好指定为NOT NULL,除非需要用到NULL.如果查询中包含

《高性能MySQL》读书笔记--Schema与数据类型优化

1.慢查询 当一个资源变得效率低下的时候,应该了解一下为什么会这样.有如下可能原因:1.资源被过度使用,余量已经不足以正常工作.2.资源没有被正确配置3.资源已经损坏或者失灵因为慢查询,太多查询的实践过长而导致堆积在逻辑上.慢查询到底是原因还是结果?在深入调查前是无法知晓的.记住,在正常的时候这个查询也是正常运行的.一个查询需要filesort和创建临时表并不一定意味着就是有问题的.尽管消除filesort和临时表通常来说是"最佳实践". 2.MySQL数据类型 更小的通常更好:一般情