选择合适的数据类型
CHAR与VARCHAR
- 存储字符串,保存和检索方式不同,CHAR固定长度,VARCHAR可变长度。
- 对比图:
- 严格模式下,若实际值超出字段定义长度,将会抛出错误。
- 范例:
-- 建表
mysql> CREATE TABLE vc (v VARCHAR(4), c CHAR(4));
Query OK, 0 rows affected (0.29 sec)
-- 插入数据
mysql> INSERT INTO vc VALUES('ab ', 'ab ');
Query OK, 1 row affected (0.09 sec)
-- 查询
mysql> SELECT CONCAT(v, '+'), CONCAT(c, '+') FROM vc;
+----------------+----------------+
| CONCAT(v, '+') | CONCAT(c, '+') |
+----------------+----------------+
| ab + | ab+ |
+----------------+----------------+
1 row in set (0.06 sec)
- CHAR比VARCHAR速度快得多,但浪费存储空间。随着MySQL对VARCHAR的性能提升,很多应用也经常用VARCHAR。
- 不同存储引擎对CHAR,VARCHAR的使用原则有所不同:
TEXT与BLOB
- BLOB可保存二进制数据,TEXT只能保存字符串数据。
- BLOB和TEXT会带来一些性能问题,特别是删除操作。删除会留下一些空洞,对以后插入数据到该空洞会有影响,可定期使用OPTIMIZE TABLE进行优化。如,
mysql> CREATE TABLE blob_test(
-> id INT NOT NULL AUTO_INCREMENT,
-> content TEXT,
-> PRIMARY KEY (id))ENGINE=MyISAM;
Query OK, 0 rows affected (0.34 sec)
插入一些数据后,数据文件大小为:
mysql> SELECT count(1) FROM blob_test;
+----------+
| count(1) |
+----------+
| 12288 |
+----------+
存储文件大小此时大于7M:
我们删除一些数据后,文件大小并没有变:
mysql> DELETE FROM blob_test WHERE id > 5000;
Query OK, 7288 rows affected (0.16 sec)
当我们执行优化OPTIMIZE TABLE blob_test后,文件大小才缩小:
mysql> OPTIMIZE TABLE blob_test;
+---------------------+----------+----------+----------+
| Table | Op | Msg_type | Msg_text |
+---------------------+----------+----------+----------+
| mysqltest.blob_test | optimize | status | OK |
+---------------------+----------+----------+----------+
1 row in set (0.08 sec)
- 可以使用合成的(Synthetic)索引来提高大文本字段(BLOB或TEXT)的查询性能。
- 在不必要的时候避免检索大型的BLOG或TEXT值。
- 可以把BLOG或TEXT列分离到单独的表中。这会加少主表的碎片。
浮点数与定点数
- 对于浮点数,如果插入的值的精度超过定义的精度,则会四舍五入;如果SQLMode为Tranditional,若插入值的精度大于定义的精度,则会报错。
- 定点数与浮点数不一样。定点数以字符串存储,精度更高。
- 使用浮点数和定点数的几个原则:
1. 浮点数存在误差问题;
2. 对货币等对精度敏感的数据,应采用定点数来表示或存储;
3. 若程序中用到浮点数,要注意其误差问题,尽量避免浮点数比较;
4. 注意浮点数中一些特殊值的处理。
日期类型选择
- 对于日期类型的选择在前面的文章也详述过,这里作个简单的总结:
不吝指正。