mysql 字段长度txt长度对内存的影响吗

来源：蜘蛛抓取(WebSpider) 时间：2017-09-08 06:44 标签： mysql datetime 长度
5421人阅读
笔试面试（102）
mysql（58）
1、从内存中读取数据是微秒级别的。而从磁盘读则是毫秒级别的。二者相差一个数量级。所以想优化数据库，第一个要做到的就是优化io。
2、key_buffer_size[global]设置的内存区域大小缓存了myisam表的索引。由于myisam只缓存索引在内存中，并不缓存数据在内存，所以如果内存允许，要让这个参数足够能容纳所有myisam的所有索引来提高性能。另外，在myisam表上，尽量让所有的查询条件都限制在索引上，以便能让缓存替我们提高查找效率。
3、bulk_insert_buffer_size[thread]仅仅用在myisam中，用于在插入数据的时候临时缓存数据。当我们使用如下的写入语句的时候，会使用这个内存区域帮助批量写入数据文件：
insert ... select ...
insert into ... values ...
load data infile ... into ...
4、innodb_buffer_pool_size[global]当我们使用innodb引擎的时候这个参数也许是影响性能最为关键的一个参数了。它用来设置缓存innodb的索引以及数据块的内存区域大小。
简单来说，我们操作innodb表的时候，返回的所有数据以及去查找数据的过程中所用到的所有索引，都会在这个内存块中走一遭。
5、innodb_additional_mem_pool_size[global]设置了innodb存储引擎用来存放数据字典信息以及一些内部数据结构的内存区域大小。所以，当我们一个mysql instance中
包含有很多数据库对象（比如很多表的时候）的时候需要适当调整该参数的大小以确保所有的数据都在内存中，以确保效率。这个参数的内存是否足够还是比较容易知道的。因为当过小的时候
mysql会记录warning到error log中的。
6、innodb_log_buffer_size[global]innodb事务所使用的内存。innodb在写事务日志的时候，为了提高性能，先写入缓存，再写到logfile中。
7、innodb_max_dirty_pages_pct[global]用来控制在innodb的buffer pool中，可以不用写入数据文件的dirty page(已经被修改，但是还没写入到数据文件的脏数据)的比例。
这个值越大，从内存到磁盘的写入操作就会减少。所以能够一定程度减少磁盘io。但是当这个值很大的时候，如果数据库crash，那么重启的时间可能就会很长。因为会有
大量的事务数据需要从日志文件中恢复出来写入到数据文件中。同时，过大的比例值，也会造成当达到比例设定的上限之后，flush操作写入数据“过猛”，造成性能波动剧烈。
8、当我们要取出全表大部分的数据的时候 ，索引扫描不一定优于全表扫描。
9、mysql是基于行的数据库，而数据读取则是基于page的。每个page中存放有行。如果每一行的数据量都减小，那么每个page里面存放的行就增多了。每次io就能偶取出更多的行。
反过来，处理相同的数据，处理的page就会减少。也即是io次数的降低。直接提升性能。此外，由于我们的内存数量是有限的，那么每个page中行数增多了，就等于增加了
每个数据块的缓存数据量，也能够提升命中率。
10、我们无法改变要存储什么数据，但是怎么存储数据我们可以花一些心思。
1）数字类型。万不得已，不要用double类型。除了占用空间比较大之外，还有精度问题。同样，固定精度的小数也不要使用decimal，建议乘以固定倍数，转换成整数进行存储。
可以节省存储空间，而且不用任何附加维护成本。对于整数的存储，建议分开tinyint/int/bigint，他们存储数据占用空间有一定差距。
2）字符类型。万不得已，不要用text类型。它的处理效率低于char和varchar。定长字段建议char类型。变长用varchar。varchar切不可以随意给一个很大的长度。因为不一样的长度范围，mysql会有不同的处理。在博客中有一篇是介绍varchar的处理方式的。假设声明了varchar(1000)，那么，mysql在磁盘中存储这个数据的时候，假设数据长度45，那么磁盘中就占用大概45左右的空间。但是当这个数据在内存中的时候还是要占用1000个空间的。浪费了很多。
3）事件类型。尽量使用timestamp。存储空间占用只是datetime类型的一半。对于需要精确到某一天的类型，建议使用date类型。因为它存储需要三个字节。比timestamp还少。
不建议使用int来存储一个unix timestamp，不直观，不会带来任何好处。
4）适当对表中字段进行冗余。比如说，把一个文章的摘要，与文章信息表放在一起，而不是跟文章详细内容表放在一起。
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：1916632次
积分：17008
积分：17008
排名：第589名
原创：340篇
转载：17篇
评论：197条
(1)(1)(2)(11)(9)(31)(1)(1)(12)(78)(13)(22)(41)(11)(68)(32)(8)(1)(3)(13)mysql中varchar长度与实际物理内存的关系 例如256个汉字算多少长度，占用多少内存_百度知道
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。
mysql中varchar长度与实际物理内存的关系 例如256个汉字算多少长度，占用多少内存
我有更好的答案
要看你的编码格式，utf-8占三字节，gb2312占二字节比如你的格式是utf-8那么varchar(1)的长度就是占用三字节。可以存一个汉字或字母，而这个汉字或字母就是占了三个字节
我用自己的话描述你的回到：一个汉字或字母在保存编码为utf-8的情况下占用三个字节，对应于mysql数据库中varchar内型长度为一。也就是说
类型varchar，长度500可以保存500个以内的字母或者汉字
对的，如果你想详细了解，我介绍你看一个网址,它介绍了关于varchar最大长度的问题，里面应该包含了你想知道的内容或者可以看mysql官方手册关于char 和varchar的介绍
采纳率：39%
来自团队：
512字节 吧！
为您推荐：
其他类似问题
物理内存的相关知识
等待您来回答对mysql存储性能优化的基本理解
这几天了解了下关于的性优化和设计方面的内容，现在做一下自己学习的小结，后续我会继续深入学习，完善下总结：
1、使用索引
每张表最多可以做16个索引，支持多列索引和全文索引
建立索引：create index index_name on users(username);
查看索引：s
是一把双刃剑，建不建立索引，主要看表的功能，找好一个平衡点，。
2、使用explain分析查询
在查询在用explain
3、调整mysql内部配置
(1)、改变索引缓冲区长度（key_buffer）；
推荐设置整个内存的25%。
(2)、改变表长(read_buffer_size)
当数据库对某个表进行频繁的扫描的时候，mysql会分配一段内存缓冲区，如果觉得扫描进行的太慢，可以适当将该值大小。
(3)、设定打开表的数目的大小(table_cache)
该变量控制mysql在任何时候打开表的最大数目，由此来控制服务器响应输入请求的能力。他跟max_connections
(4)、对缓查询设定一个时间限制(long_query_time)
ySQL带有“慢查询日志”，它会自动地记录所有的在一个特定的时间范围内尚未结束的查询。这个日志对于跟踪那些低效率或者行为不端的查询以及寻找优化对象都非常有用。long_query_time变量控制这一最大时间限定，以秒为单位。也可设置为ms，但是需要打补丁。
至于安全方面的考虑，比如测试数据库和线上分离、备份、主从等，这些后续再谈，时间紧迫，先写这么多，待续...

我要回帖

更多关于 mysql datetime 长度 的文章

 

随机推荐