易栈网-膘叔

今天我们继续学习一下MYSQL的数据类型
浮点型
从MYSQL3.23开始，FLOAT和DOUBLE类型就一直分别对应着IEEE标准所定义的单精度浮点数和双精度浮点数，绝大多数编程语言也都支持这两种数据类型。
当某个字段设置成这两种类型时，会要求按(m,d)这样的格式输入参数，其中m和上文介绍INT时所讲的m效果一样，仅仅在显示/打印结果时有一定的排版作用，而对数据的精确度没有影响。可是d这个参数就不一样了,d代表了小数点后面的数字个数，而且会按照d的大小来进行四舍五入，例如：1234.5678如果存储到FLOAT(8,3)这样的字段里，实际存放的是1234.568，最后一位会四舍五入。
存储FLOAT和DOUBLE时，如果超出了这两种类型的范围，将会被替换成该类型的最大可取值（一般由当前操作系统决定，我不知道MYSQL是怎么样。），可以使用SHOW WARNING来查看警告内容。
MYSQL对浮点数有一定的要求，即一定要符合通用计数法，小数点一定是“.”，而不能是“,”（因为有部分欧洲国家使用逗号作为小数点，我也是第一次听说，黑黑），MYSQL永远会以这种写法向客户返回查询结果，只有在非常大或非常小的数值，会采用科学计数法表示，如1.234E+017。如果想让浮点数表现形式变成其他样式，有两种方式：一是利用SQL查询中的FORMAT函数，二是用客户端程序中的FORMAT函数，例如php中就可以使用sprintf或者number_format等来改变显示效果

说到浮点数，当然要提定点数了
正因为MYSQL在处理浮点数时，最后一位会被自动的四舍五入，而我们实际上并不需要这一位被四舍五入（比如在处理财务数据时），怎么办呢？定点数可以解决这个问题。
定点数（DECIMAL）数字是以字符串的形式来进行存储的，并且不被允许存储指数形式，每位数字占用一个字节，外加两个字节的开销，所以，占用了更多的空间，但可表示的数值范围却比较小。
在进行存储的时候，也有两个参数DECIMAL(p,s)这回，这两个参数都有作用了。p代表了数据的总位数（不含小数点），最大65，s代表了小数点后的数字位数，最大为30。比方说：DECIMAL(6,3)取值范围为-999.999~999.999，这是新的版本的表示方法。不知道我有没有记错，我记得在以前的版本里，DECIMAL(6,3)，这个6并不是代表了总位数，而是小数点前的位数（可能是在4.0吧）。
在MYSQL内部，定点数是被保存为二进制格式的，把定点数从小数点开始分割，并为它们各自分配所占用的字节数（最初是以每4个字节进行划分，虽然每个字节可以容纳2位数字，但4个字节却可以容纳9位数字，超过4个字节后，如果有多出的数字就划分一个字节来进行存储，同样如果是9位数字，还是只占4个字节）。根据这个规定，我们可以认为DECIMAL(6,3)其实是和DECIMAL(18,9)占用了同样多的字节数（8个字节）。如此说来DECIMAL(19,9)实际就占用了9个字节。

参考：http://dev.mysql.com/doc/refman/5.0/en/storage-requirements.html

介绍完表的结构和存放位置后，下面的内容就是介绍MYSQL的数据类型了，毕竟为你想要的数据选定一个合适的类型，对于数据库的存取效率有很大的改进。
MYSQL数据库有以下几种类型：整数型(int,binint,smallint,tinyint等等xxxint型)、浮点型(float,double,real等)、定点数型(decimal，也就是传说中的浮点型的字符串表达形式)、日期与时间型（data,time,datetime,timestamp），字符串型（char,varchar,text,tinytext,mediumtext,longtext等），二进制型（tinyblob,tinyblob,blob等blob型），枚举型(enum,set——set是类似于enum型)。

下面从整数型开始详细介绍这些数型的基本信息：
整数型
默认情况下，INT类型既包括正数，也包括负数，如果给INT列定义UNSIGNED属性，那么它的取值范围就永远是正数。这个永远是正数，非常重要，即，如果你在对数据列操作：update tablename set int_field = (int_field - 1000 )，如果int_field的值小于1000，理论上是变成了负数，但由于你设的属性是UNSIGNED，那么存储的数据仍然是无符号的正数，这可能会给你带来虚假或让人困惑的结果。
TINYINT的取值范围是从-128~+127，如果使用了UNSIGNED属性，那么它的取值范围就变成了0~+255。如果用户试图存入超过字段取值范围的数字，MYSQL所做的工作就非常简单，它会直接替换成最大可取值或最小可取值。
或许有人注意到，我们在使用phpmyadmin的时候，如果选择INT类型，那么后面有一个可选长度。不过，千万不要被这个数值所迷惑，因为它的实际功能并非指定该INT类型的长度，而是最大显示宽度（M：Maximum Display Width），仅仅用于查询数据时可以把查询结果按照你所指定的宽度进行显示，最主要的用途是为了排版需要。虽说是这样，但在一些很少见的特定场合（MYSQL在执行一些需要借助于临时数据表才能完成的复杂查询）里，临时数据表的数值有可能会被截短并导致最终结果不正确。因此，除非你与数据库所有的操作都在命令行下执行，否则，还是建议留空。

上面tinyint(m)括号中的m，就是上文所指的最大显示宽度。最后一个serial含义里的auto_increment，代表了该字段是自增字段，即，往有该属性的字段里插数据时，系统会自动把该字段的当前最大值加上1后存进去。 一般而言，该属性往往用于主键字段。在使用该属性时应当注意以下几个问题。
1、该属性必须与NOT NULL、primary Key 或者 Unique属性同时使用。
2、每个数据表只能存有一个auto_increment属性的数据列
3、该属性一般是在进行数据插入时，没有明确指定值或者指定值为NULL时，才起作用。如果指定了值，并且该值还没有出现过，MYSQL将使用该值插入，以生成一条新记录。这时候就有两种情况：a)原有的数据是1~100，后来删除了20~80的内容，即数据库里只存在1~19,81~100的数据，当插入ID为20的数据时，数据库还是会按照规则，把20这条记录插进去，并不会报错，自增值仍然是100，下次正常插入时，还是会默认使用101这个值。b)原有的数据是1~100，我插入ID为1000的数据时，不会报错，但自增值变为1000，下次插入数据从1001起算。（啰嗦了点，但应该记住）
4、如果想知道刚刚插入的数据值是多少，在插入数据后，可以使用select last_insert_id()语句获取。在PHP中，有一个函数是:mysql_insert_id()，该函数不是很建议使用，因为它返回的数据是INT型，如果auto_increment所在的数据列类型是bigint，而且实际值已经超过int类型最大值的话，mysql_insert_id()返回的值，将不正确。
5、如果auto_increment计数器达到了最大值（即该字段所允许的最大值），将不再递增，因此数据插入将无法执行。其实是到了最大值后，MYSQL会永远将该字段的最大值往数据库里插，因此造成MYSQL报：该数据列已存在的错误。
6、如果在可行范围内，或者预计数量会很大的情况下，尽量使用你想要设定的数据类型的再上一层类型，但尽量不要太夸张。比如你预计你的用户数不会超过1000000万，表面上medimum无符号已经够用了，但这时候，仍然建议你使用int型，以防万一。

打字很累，剩下的留到以后慢慢讲。。。

差点忘了。。。还有个BIT和BOOL，在MYSQL中，关键词BOOL是TINYINT的同义词，在5.0.2以及以前的版本中，BIT也是如此。但是从5.0.3开始，BIT不再是TINYINT的同义词，而是一种可以存储多达64位二进制数值的新数据类型。这个在以后会单独介绍，这里一笔带过先。

明天，就是俺结婚2周年的纪念日了，为了感谢大家的支持，所以。今天再开放一篇连载。黑黑

介绍完MYSQL所支持的一些数据表类型，再介绍一下数据表文件的存放等资料。

MYSQL对于数据表的存放一般而言都是很有规律的，在*nix系统下面，通常在/var/lib/mysql子目录，而在windows平台下一般都在mysql安装目录下的子目录/data/里。

（写了一半，发现都需要用到数据存放目录，现在假设数据存放目录为/data/）

一般而言，每一个数据表都有一个和表名对应的frm文件，而这些数据表都是存储在以它本身所在数据库为名的目录里。例如：User数据库下的members表，一般都存储在数据库目录下的/User/下，名字为members.frm（全路径为：/data/User/members.frm）。frm文件是整个数据库的结构定义和设置。

如果是myisam数据表，那么还会创建两个以数据表命名的文件，*.MYD,*.MYI，其中MYD文件用来存放MYISAM数据表的数据，而MYI文件用来存放索引（该表的所有索引）。

如果是innoDB数据表的话，就需要根据MYSQL配置文件中的innodb_file_per_table的选项设置情况而定。它既可以各自存为一个文件，也可以统一存放在所谓的表空间(tablespace)里。表空间的存放位置和名字由配置决定。如果没有做任何设置的话，默认是innodb数据表的数据和索引存放在/data/dbname/tablename.idb文件里，而把表空间和撤销日志（undo log）存放在/data/ibdata1,/data/ibdata2/...等文件里，而把innodb的日志数据存放在/data/ib_logfile0 ,/data/ib_logfile1这样有规则的文件里。

在如今的版本里，如果你定义了触发器，那么它们存放在/data/databasename/tablename.TRG文件里。新版本据说可能会发生变化。

（今天晚上要读书，所以先发上来）

 昨天我们讲的是myisam表的特性，今天我们来讲讲innodb的一些特性。

 单位今天请MYSQL公司的人来进行了简单的辅导和介绍。上午的我没有参加，下午的因为涉及到了一些SQL优化之类的，同事让我也听听学习学习。

一开始的时候讲了一大堆存储的事，可惜都是那种很空洞的感觉。不过想想也是，这种利用PPt来进行介绍的，怎么可能介绍的很详细，当时就有一种受骗的感觉。呵呵

这种课程听的再多恐怕也是和没听没啥区别吧。

唯一有印象的就是，数据库的设计规范，但也没有讲什么具体的，只是简单的说了一下：
1、能用int的，坚决不用bigint
2、如果能够基本确定长度，那就写上固定的varchar(10)，而不是varchar(255)，虽然最终存储的长度一样。
3、不要随便为某个字段增加索引，可以通过一句SQL来分析一下表（汗，忘了是什么命令了。啥时候有空翻翻手册应该就知道了）
4、如果可能，请尽量为字段设定NOT NULL（毕竟使用BTree的索引时，NULL是不在检索范围之内的）

反正，就感觉，我们里面的一些同事设计的表，完全符合他提出的这些问题，我好满足啊。他们主动要求，表一定要default NULL。

还有对我有印象的就是，如果某字段的值几乎一致，比如：a_123,a_456,建议使用前缀索引（MYSQL4好象没有这个？）不过确实这个从来没有注意过。。。

其他的什么分表存储，水平，垂直，都只是空泛的介绍。而没有实质性的东西。。。

当然，主要是因为这其中的大部分知识，我还是略有所知的。。。

总算还是略有收获，没有完全浪费1小时左右的时间。不过，这位介绍人员的介绍有点生疏，黑黑。。。害羞？还是初次从后台走向前台？不得而知。。。