高性能的MySQL(4)数据类型的优化

一、基本原则

1、更小的通常更好

更小的数据类型通常更快,因为占用更少的磁盘、内存和CPU缓存,并且处理时需要的CPU周期也更少。

但是要确保没有低估需要存储的值的范围,因为在schema中的多个地方增加数据类型的范围是个非常耗时的操作。

2、简单就好

例如,整数比字符串操作代价更低,应该用内建类型而不是字符串来存储时间和日期,用整型存储IP。

3、尽量避免NULL

可为NULL的列使用更多的存储空间,需要特殊的处理。特别是可为NULL的列被索引时,每个索引需要额外的字节,在Myisam引擎里甚至还可能导致固定大小的索引,所以计划建立索引的列,要避免使用NULL。

二、数据类型

1、整数类型

TINYINT、SMALLINT、MEDIUINT、INT、BIGINT,分别使用8、16、24、32、64位存储空间。范围从-2(N-1)次方到2(N-1)次方-1。

指定范围,只是一种显示,对存储和计算来说INT(1)和INT(20)是一样的。

2、实数类型

FLOAT和DOUBLE支持使用标准的浮点运算进行近似计算。

DECIMAL类型用于存储精确的小数

浮点类型在存储同样的范围的值是,通常比DECIMAL使用的空间更少。因为额外的空间和计算开销所以应该只在对小数进行精确计算时才使用,也可以考虑使用BIGINT代替DECIMAL,将小数的位数乘以相应的倍数即可。

3、字符串类型

VARCHAR类型用于存储可变长字符串,但是需要1-2个额外字节记录字符串的长度。由于行是变长的,在UPDATE时不同的引擎需要不同的额外处理工作。同时存储和检索时会保留末尾空格。

CHAR类型是定长的。存储时会删除末尾的空格。

对于字符串最大长度比平均长度大很多,列的更新很少,适合VARCHAR。对于经常更新的数据,CHAR更好,因为不容易产生碎片。

4、BLOB和TEXT类型

都是为存储大的数据而设计的字符串类型,分别采用二进制和字符方式存储,BLOB没有排序规则和字符集。

MySQL对BLOB和TEXT列进行排序和其他类型是不同的,它只针对每个列的最前max_sort_length字节排序,或者使用order by substring(column,length).

如果查询使用了BLOB和TEXT列并且需要使用隐式临时表,将不得不用到MYIASM磁盘临时表,这是很大的系统开销。如果无法避免,有一个技巧是在所有使用到BLOB字段的地方使用substring(column,length)将列值转换为字符串,这样就可以使用内存临时表了。但是要确保截取的字符串足够短,不会使临时表的大小超过max_heap_table_size和tmp_table_size,如果超过还是会使用磁盘临时表的。

如果explain的Extra列包含“Using temporary”,则说明用到了隐式临时表

5、ENUM类型

把一些不重复字符串存储成一个预定义的集合,非常节省空间。mysql在内部会将每一个值在列表中的位置保存为整数,并且在表的.frm文件中保存“数字-字符串”的映射关系的查找表。只有在进行查找时才会转化为字符串。

时间: 2024-10-30 12:00:46

高性能的MySQL(4)数据类型的优化的相关文章

高性能的MySQL(8)优化服务器配置:并发和负载

当MySQL遇到高并发时,可能会遇到不曾遇到的瓶颈. 一.InnoDB并发配置 InnoDB是为高性能设计的,在最近几年他的提升非常明显,但依然不完美. InnoDB有自己的 "线程调度器"控制线程怎么进入内核访问数据,以及他们在内核中一次可以做哪些事情.最基本的限制并发的方式是使用innodb_thread_concurrency变量,它会限制一次性可以有多少个线程进入内核,0表示不限制. 理论上,下面的公式可以给出一个这样的值 并发值 = CPU数量 * 磁盘数量 * 2 但是在实

高性能的MySQL(8)优化服务器配置:I/O

有一些配置项影响着MySQL怎样同步数据到磁盘以及如何做恢复操作,这写操作对性能影响很大,因为都设计到昂贵的I/O操作,通常保证数据立刻并且一致的写到磁盘是很昂贵的,有的时候不得不冒一点险,延迟持久化到磁盘,来增加并发和减少I/O等待. 一.InnoDB I/O配置 对于常见的应用,InnoDB日志文件大小.InnoDB怎样刷新日志缓冲,以及怎样执行I/O比较重要. a.InnoDB事务日志 InnoDB使用日志来减少提交事务时的开销,日志记录了事务,就无须在每个事务提交时把缓冲池刷新到磁盘中了

高性能的MySQL(8)优化服务器配置:内存

配置MySQL服务器离不开配置文件,接下来就开始这一部分的内容. 首先一定要清楚配置文件的位置,如果不知道可以尝试下面的操作: /usr/local/mysql/bin/mysqld  --verbose --help | grep -A 1 'Default options' #结果如下 Default options are read from the following files in the given order: /etc/my.cnf /etc/mysql/my.cnf /usr

高性能的MySQL(8)优化服务器配置:安全与稳定

在前面的章节已经介绍了一些选项,还有一些剩余的也很重要的选项,我们继续说明一下: 一.基本配置 tmp_table_size 和 max_heap_table_size 这2个设置控制使用Memory引擎的内存临时表能使用多大的内存.如果隐士内存临时表的大小超过这2个设置,将会被转换为磁盘临时表.隐士临时表是一种并非自己创建,而是服务器创建,由于保存执行中的查询的中间结果的表. 临时表最好呆在内存里,但是如果它很大,实际上还是使用磁盘比较好,否则可能会内存溢出. 可以使用show status

MySQL学习第六天 学习MySQL基本数据类型_Mysql

还记得上一篇学习的内容吗?不记得再看一看MySQL学习第五天 MySQL数据库基本操作,温故可以知新!         数据类型是指列.存储过程参数.表达式和局部变量的数据特征,它决定了数据的存储方式,代表了不同的信息类型.MySQL中常用的的数据类型包括:数值类型.日期和时间类型和字符串类型等.  一.数值类型        MySQL支持所有标准SQL中的数值类型,其中包括严格数据类型(INTEGER.SMALLINT.DECIMAL.NUMBERIC),以及近似数值数据类型(FLOAT.R

运维多年经验详谈MySQL数据应该如何优化

数据库的设计可能只会根据当时的业务需求来设计,可能当时并不需要高可用.高伸缩等特性的,但是随着业务及用户量的增加,基础架构才逐渐完善.这篇博文主要谈MySQL数据库发展周期中所面临的问题及优化方案,暂且抛开前端应用不说,大致分为以下五个阶段: 1.数据库表设计项目立项后,开发部根据产品部需求开发项目,开发工程师工作其中一部分就是对表结构设计.对于数据库来说,这点很重要,如果设计不当,会直接影响访问速度和用户体验.影响的因素很多,比如慢查询.低效的查询语句.没有适当建立索引.数据库堵塞(死锁)等.

【转载】低成本和高性能的MySQL云数据库的实现淘宝 MySQL

低成本和高性能的MySQL云数据库的实现 作者: 鸣嵩/曹伟(集团技术专家) 本文刊登于<程序员>杂志2012年12期上,转载请注明         UMP(Unified MySQL Platform)系统是淘宝核心系统数据库团队开发的低成本和高性能的MySQL云数据方案,关键模块采用Erlang语言实现.系统中包含了controller服务器.proxy服务器.agent服务器.API/Web服务器.日志分析服务器.信息统计服务器等组件,并且依赖于Mnesia.LVS.RabbitMQ.Z

101个MySQL的调节和优化的提示

  MySQL是一个功能强大的开源数据库.随着越来越多的数据库驱动的应用程序,人们一直在推动MySQL发展到它的极限.这里是101条调节和优化 MySQL安装的技巧.一些技巧是针对特定的安装环境的,但这些思路是通用的.我已经把他们分成几类,来帮助你掌握更多MySQL的调节和优化技巧. MySQL 服务器硬件和操作系统调节: 1. 拥有足够的物理内存来把整个InnoDB文件加载到内存中--在内存中访问文件时的速度要比在硬盘中访问时快的多. 2. 不惜一切代价避免使用Swap交换分区 – 交换时是从

Mysql数据表的优化方法总结

优化表的数据类型 表需要使用何种数据类型,是需要根据应用来判断的.虽然应用设计的时候需要考虑字段的长度留有一定的冗余,但是不推荐让很多字段都留有大量的冗余,这样即浪费存储也浪费内存. 我们可以使用PROCEDURE ANALYSE()对当前已有应用的表类型的判断,该函数可以对数据表中的列的数据类型提出优化建议,可以根据应用的实际情况酌情考虑是否实施优化.语法:  代码如下 复制代码    SELECT * FROM tbl_name PROCEDURE ANALYSE();    SELECT

查询速度-mysql表字段select优化

问题描述 mysql表字段select优化 在一张表中,字段contentbody数据类型mediumtext,在contentbody中加 插入了大量的文字内容,如果在select查询过程中查询出contentbody, 则查询速度四五秒左右,非常慢,请问,有没有什么可优化 select contentbody from content这个sql的查询速度? 解决方案 建议你的select contentbody from content 后面增加where条件,只取需要的数据,或者根据需要分