对比MySQL中int、char以及varchar的性能

区别 CHAR与VARCHAR类型类似,但它们保存和检索的方式不同.CHAR有固定的长度,而VARCHAR属于可变长的字符类型.它们最大长度和是否尾部空格被保留等方面也不同.在存储和检索过程中不进行大小写转换. 下面的表格显示了将各种字符串值保存到CHAR(4)和VARCHAR(4)列后的结果,说明了CHAR和VARCHAR之间的差别: 值 CHAR(4) 存储需求 VARCHAR(4) 存储需求 '' ' ' 4个字节 '' 1个字节 'ab' 'ab ' 4个字节 'ab' 3个字节 'ab

在上篇文章给大家讲了MySQL数据库中把int转化varchar引发的慢查询,本文给大家介绍Mysql数据库中把varchar类型转化为int类型的方法,一起看看吧! mysql为我们提供了两个类型转换函数:CAST和CONVERT,现成的东西我们怎能放过? CAST() 和CONVERT() 函数可用来获取一个类型的值,并产生另一个类型的值. 这个类型 可以是以下值其中的 一个: BINARY[(N)] CHAR[(N)] DATE DATETIME DECIMAL SIGNED [INTEG

最近一周接连处理了2个由于int向varchar转换无法使用索引,从而引发的慢查询. CREATE TABLE `appstat_day_prototype_201305` ( `day_key` date NOT NULL DEFAULT '1900-01-01', `appkey` varchar(20) NOT NULL DEFAULT '', `user_total` bigint(20) NOT NULL DEFAULT '0', `user_activity` bigint(20)

UTF8字符集下: SQL>create table test(id int auto_increment,name varchar(10),primary key(id)); SQL>insert into test values(null,'1234567890'); Query OK, 1 row affected (0.00 sec) SQL>insert into test values(null,'一二三四五六七八九十'); Query OK, 1 row affected

虽然这种情况不应该发生,通常像我们关系型数据库,我们应该是事先设计好,以后不能改动,但是由于之前工作的疏忽,其实说实话,也不仅仅是我个人的疏忽,主要是沟通上的原因,当然数据库毕竟是我设计的,所以,还是自我批评一下. 说一下情况:MySQL字段有个varchar值字段设置的太短了,设置了30个,(我依稀记得varchar是可扩展的,当然现实并不容忍我的依稀),所以我只能找一个方法在保证数据库数据不变的情况下,动态修改varchar字段的长度,找了一段时间,终于让我找到了. alter table

有的小伙伴在学习数据库的时候,创建表结构的时候不小心把某字段设置成了varchar但是在统计求和的时候就傻眼了,接下来跟着小编学习一下,不用改该列数据类型也能求和的方法吧! 1.打开 数据库连接客户端Navicat Premium ,创建一个新的表结构,这里age这列 故意 设置为 varchar. 2.创建表成功之后,为刚刚的表创建一些测试的数据,这里如下图: 3.在数据量少的时候可以使用sum()函数直接求和,因为MySQL中它可以自动识别是字符串类型还是数字类型. 4.以上适用于整数,或者

如果某一项中设置的是varchar(50) 那么对英文当然是50 那么对中文呢 utf-8的中文占3个字节 那么,这个varchar(50)是不是只能存16个汉字了? mysql varchar(50) 不管中文 还是英文 都是存50个的 MySQL5的文档,其中对varchar字段类型这样描述:varchar(m) 变长字符串.M 表示最大列长度.M的范围是0到65,535.(VARCHAR的最大实际长度由最长的行的大小和使用的字符集确定,最大有效长度是65,532字节). 为何会这般变换?真

网络上有许多似是而非的"谣言",当然都不是恶意,绝大部分都是开发者不愿意自己主动研究,反而轻信其他人的信口之言. 关于数据库的谣言也有不少,比如"int性能比char高很多". 我最近针对int.long.char.varchar进行了一次性能测试,发现它们其实并没有太大的性能差距: 备注:c8=char(8), s8=varchar(8), i8=(bigint), c4=char(4), s4=varchar(4), i4=char(4) 100w行无索引情况下

你可能已经知道int(1)这个长度1并不代表允许存储的宽度! 但对这个长度很多人也没有真正研究过到底代表什么,今天我就来简单的分析一下! 先看一个简单的建表小案例: create table test( id int(11) unsigned NOT NULL AUTO_INCREMENT, uid int(3) NOT NULL, PRIMARY KEY (id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; 这里以uid字段为例,我们这里设置的是int(3

目录 困惑 数据说话 零填充 总结 困惑 最近遇到个问题,有个表的要加个user_id字段,user_id字段可能很大,于是我提mysql工单alter table xxx ADD user_id int(1).领导看到我的sql工单,于是说:这int(1)怕是不够用吧,接下来是一通解释. 其实这不是我第一次遇到这样的问题了,其中不乏有工作5年以上的老司机.包括我经常在也看到同事也一直使用int(10),感觉用了int(1),字段的上限就被限制,真实情况肯定不是这样. 数据说话 我们知道在mys

目录 一.背景 二.MySQL整数类型 总结: 一.背景 在创建数据库表的时候,我们经常会用到int(x)来定义一个字段的类型,一直误以为这里的x表示存储数字的长度. 其实大错特错,这里的 x 指的是 最大显示宽度(最大有效显示宽度是255),且显示宽度与存储大小或类型包含的值的范围无关. 二.MySQL整数类型 类型 字节 取值范围 显示宽度 tinyint 1 -128 ~ 127 4 smallint 2 -32768 ~ 32767 6 mediumint 3 -8388608 ~ 83

导语 前两天看到的问题,展开写一下. 字节 我们都知道计算机是以二进制为基础.存储的基本单位是 Bit,也称为比特.二进制位.1bit 可以表示 0 或者 1 两个数字,是可能存在的最小的信息量,任何小于1 bit 的内容都算不上信息. 复杂的内容就要用多 bit 来表示.Byte ,也称为字节,通常用作计量单位.1 byte 等于 8 bit,即 1 byte 可以表示 28 内容. MySQL 中的字节 先说明一下,在 MySQL 中的整数类型,可以分为 unsigned 和 signed

最近使用mysql数据库的时候遇到了多种数字的类型,主要有int,bigint,smallint和tinyint.其中比较迷惑的是int和smallint的差别.今天就在网上仔细找了找,找到如下内容,留档做个总结: 使用整数数据的精确数字数据类型. bigint 从 -2^63 (-9223372036854775808) 到 2^63-1 (9223372036854775807) 的整型数据(所有数字).存储大小为 8 个字节. P.S. bigint已经有长度了,在mysql建表中的len

show profile是由Jeremy Cole捐献给MySQL社区版本的.默认的是关闭的,但是会话级别可以开启这个功能.开启它可以让MySQL收集在执行语句的时候所使用的资源.为了统计报表,把profiling设为1 mysql> SET profiling = 1; 之后在运行一个查询 mysql> SELECT COUNT(DISTINCT actor.first_name) AS cnt_name, COUNT(*) AS cnt -> FROM sakila.film_act

在MySQL中,char.varchar和text类型的字段都可以用来存储字符类型的数据,char.varchar都可以指定最大的字符长度,但text不可以. 它们的存储方式和数据的检索方式也都不一样. 数据的检索效率是:char > varchar > text 具体说明: char:存储定长数据很方便,CHAR字段上的索引效率级高,必须在括号里定义长度,可以有默认值,比如定义char(10),那么不论你存储的数据是否达到了10个字节,都要占去10个字节的空间(自动用空格填充),且在检索的时